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

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

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.

Reg." fallbackLocale": “he” and RTL: the fallbackLocale is a configuration per resource bundle whereas the RTL flag is a global thing in UI5. If one bundle falls back to “he”, there still might be others (like SAPUI5’s own bundles) that can handle “de”).

There’s no logic that would check whether all bundles fall back to “he” and then derive RTL from that. Basically, the fallbackLocale is not meant to redirect the logon language. It is rather a last resort during development when translation is not complete yet and when the text in an otherwise supported language has not been provided yet.

If you need a kind of global fallback for the login language, you better should validate the logon languages and set sap-language accordingly.

Reg. the requests (“en” and “he”, despite limiting the fallbackLocale to “he”): that’s indeed strange and should not happen. Without the complete manifest.json, I can only guess that the request for “en” came from some other place, e.g. from the “sap.app” bundle?

Reg. “async”: using async for bootstrap (data-sap-ui-async), for the rootView and for the router (if any) is definitely recommended. Whether resource bundles for views need special treatment, I can’t say out-of-the-box. I’ll check that.