`i18n` prefix is shown within columns for new app created using `CatalogService (Java)` + entity `Authors`

[815are]

We have E2E test script which uses https://github.com/SAP-samples/cloud-cap-samples-java and creates new application using CatalogService (Java) + entity Authors. We noticed difference regarding LR authors, that some columns are rendered with {i18n>} label, but in past it was rendered without i18n prefix. Current state:

Previous state:

Difference in texts like DateOfBirth vs {i18n>DateOfBirth}.

We checked history of https://github.com/SAP-samples/cloud-cap-samples-java and we did not find that there was any change regarding i18n entries.

Fork from https://github.com/SAP-samples/cloud-cap-samples-java with code which includes addition app for Authors -> https://github.com/815are/cloud-cap-samples-java/tree/i18nIssue

Please note - our assumption was that something was changed in cds dependency and we created issue on cds -> https://github.tools.sap/cap/issues/issues/15826 . CDS team suggested to maintain translation within i18n.properties

[beckermarc]

Yes, this is indeed a slight change that was introduced by a new feature we added to CAP Java to lazily localize EDMX files (https://pages.github.tools.sap/cap/docs/releases/archive/2023/dec23#on-the-fly-localization-of-edmx). We now do the replacement of the i18n placeholder with the text lazily on $metadata request, reducing the amount of EDMX files we need to load and cache. There we don't do any replacement of unresolvable placeholders anymore, while the previously generated EDMX files from cds build replaced them with the key, stripping the {i18n>} stuff.

I actually think showing the i18n placeholder explicitly makes it more visible that you forgot to maintain i18n values for this property. I will add i18n translations for those missing labels we use on the Authors entity.

[beckermarc]

With https://github.com/SAP-samples/cloud-cap-samples-java/pull/311 now looks like this:

[815are]

thanks @beckermarc