OpenUI5 doesn't catch "i18n_he.properties", only "i18n_iw.properties" for Hebrew

OpenUI5 version: 1.77.0

Steps to reproduce the problem:

1. Set in Chrome (chrome://settings/languages) Hebrew as a priority # 1 in “Order languages based on your preference”
2. In your UI5 app create i18n_he.properties
3. Load the app

What is the expected result? UI5 will load i18n_he.properties

What happens instead? UI5 looks for i18n_iw.properties, can’t find it and tries to load the priority # 2.

Any other information? (attach screenshot if possible)

If I rename the i18n_he.properties to i18n_iw.properties everything is OK.

In Identifying the Language Code / Locale it’s written that UI5 supports:

• BCP-47
• ISO 639 alpha-2
• ISO 639 alpha-3
• ISO 3166 alpha-2

If so, then why UI5 expects iw instead of he for Hebrew?

[codeworrior]

Hi @pubmikeb,

this was indeed a problem for years. When we started UI5, our internal translation service provided an interface for the Java platform. Therefore, our ResourceBundle implementation took over the specifics of that platform, including the *.properties file format as well as the underscore in the language codes and, last but not least, the legacy ISO codes “in”, “iw”, “ji”, “no” and “sh”.

I’m sure this is documented somewhere, but I can’t find it quickly (which obviously is a problem by itself).

Luckily, since 1.77, there’s a solution for this and for other problems around localization. ResourceBundles (or more precisely, ResourceModels) that are declared in the manifest can now declare their set of supportedLocales. If this set contains “he”, the framework knows that Hebrew should be loaded from the “messagebundle_he.properties” file, whereas when the list contains “iw”, the framework will request “messagebundle_iw.properties” when the current language is Hebrew (no matter whether it is configured as “he” or “iw”).

This list of supported locales also finally helps to avoid the 404s for “en_US” etc. when those locales don’t exist in the backend. And it allows to configure the locales per bundle, which is important for bigger, componentized apps.

In 1.77, only the runtime mechanisms is present and can be used via manifest.json or via API. For future versions of the ui5-tooling, it is planned to fill the corresponding manifest entries automatically, based on the existing resources of a project.

More has been done regarding ResourceBundles and addtl. documentation will follow soon (hopefully).

HTH + Kind Regards

[codeworrior]

To avoid extra-loading or 404s, configuring the supportedLocales usually is enough. The fallbackLocale only needs to be configured, if “en” (the default fallback locale) is not part of the supportedLocales or if you think that a language other than “en” fits better to look for texts that might be missing in the other text files.

Within SAP, we create texts first in the file without locale (we call that the “raw” locale) and we create them as English text. Obviously, that file therefore would be a natural candidate for the fallbackLocale. But after translation, “en” might be more appropriate for a native speaker and therefore we introduced another fallback “en” that is checked before the “raw” file. That’s how fallbackLocale came into life.

Without any configuration, we would search the following sequence of files for a text (assuming the session language is “pt_BR”):

  pt_BR -> pt -> en -> raw locale

The search stops when a text is found.

• With the fallbackLocale you can pick another locale for the step before the raw locale
• With the supportedLocales, you can limit the whole sequence to the specified set of locales.

BTW: if you don’t need a fallbackLocale for missing text keys (because all properties files are complete or because text quality doesn’t differ between locales), then you can also configure fallbackLocale=“” and thereby skip the 3rd step above. Only makes a difference, if text files are not complete.