You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Roopa can demonstrate the problem using her test extension.
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
(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.)
Run Platform.
Verify that your extension loads as expected.
Open the Settings dialog
Drop drop the list of available Interface languages. The added locale(s) from localizedStrings.json will not be in the list.
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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:
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:
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.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'tawait waitForResyncContributions()
in getAvailableInterfaceLanguages. Maybe we just need to add that.The text was updated successfully, but these errors were encountered: