Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

If extensions contribute localizations for languages that are not known to Platform, those locales do not show in UI language setting #1400

Open
tombogle opened this issue Dec 17, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@tombogle
Copy link
Contributor

Describe the bug
Roopa's test extension contributes UI strings specific to her extension in Telugu. But Telegu (te) does not appear in the list of available UI languages in the Settings dialog.

To Reproduce
Steps to reproduce the behavior:

  1. Roopa can demonstrate the problem using her test extension.
  2. OR create a new extension with a localizedStrings.json file that has contributions using a locale that is not one of the ones in Platform's assets/localization folder
  3. (Note: by hand-editing the settings file, it is possible to select this locale in order to see that the contributions are being loaded correctly.)
  4. Run Platform.
  5. Verify that your extension loads as expected.
  6. Open the Settings dialog
  7. Drop drop the list of available Interface languages. The added locale(s) from localizedStrings.json will not be in the list.
  8. Also, if an extension tries to set the Interface language setting (platform.interfaceLanguage) to a locale that it has contributed but which is not known to Platform, it will not pass validation.

Expected behavior
The added locale(s) from localizedStrings.json (from any and all extensions) should appear in the list

Implementation note
The reason these locales do not appear is that loadAllLocalizationData (in localization.servcice-host) builds its official list of known interface locales from the filenames in assets/localization. I believe there are two architectural issues to be adcdressed:

  1. Somewhere in localizedStringsDocumentCombiner (I think transformLocalizedStringDataToCanonicalLocales), as we are processing the locales from contributions, we need to note any new locales. Since localization.servcice-host is currently where this list is held, we either need a callback or we need to make localizedStringsDocumentCombiner the authoritative keeper of UI locales.
  2. Extensions load somewhat lazily. If there is no definitive way to know that all extensions have loaded(maybe waitForResyncContributions?), we wouldn't know when we have the authoritative list of interface locales to both display in the list and also use for validation. Currently, we don't await waitForResyncContributions() in getAvailableInterfaceLanguages. Maybe we just need to add that.
@tombogle tombogle added the bug Something isn't working label Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: No status
Development

No branches or pull requests

1 participant