Skip to content

[Feature Request]: Consider loading en strings in separate i18n bundles instead of in code #12849

@scameron

Description

@scameron

Feature Request Description

I noticed today that I don't see any messagebundle resources getting loaded when my locale is set to "en". Searching around a bit, I found that the reason for this is because the keys for all of the i18n strings are baked into generated i18nBundle.js modules along with a defaultText for each one, which I believe is the English string. When the user's locale is set to "en", it uses these strings instead of loading separate i18n bundles.

There are 2 problems with this:

  1. If the user's locale is set to language that is not "en", the strings will be loaded twice. Once inlined into the code, and then again as the localized i18n bundles.
  2. Since code in UI5WC is typically statically imported by the application code, it is not uncommon for some code to be duplicated into multiple code bundles by the hosting application. In this case, there are be even more copies of the strings loaded because the defaultText strings are treated like code.

In practice, this isn't a huge problem because the UI5WC strings are very numerous or large (something like 25KB in total). But it still seems like an avoidable inefficiency and we know that strings only grow over time, never shrink.

Proposed Solution

I'm wondering if would be possible to remove all localized strings from the code and handle all languages in the same way, via separate i18n bundles that are guaranteed to only be loaded once. If a fallback is needed at the granularity of individual strings, this could be handled at build time when the bundles are generated, instead of at runtime.

Proposed Alternatives

No response

Organization

SAP Analytics Cloud

Additional Context

No response

Priority

None

Privacy Policy

  • I’m not disclosing any internal or sensitive information.

Metadata

Metadata

Assignees

No one assigned

    Projects

    Status

    New

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions