-
Notifications
You must be signed in to change notification settings - Fork 48
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
I18N design/architecture unclear #149
Comments
Thanks for the comments. I agree the current packaging spec is not clear enough to address the issue above, even though we have reserved a section of 'i18n' for further study. A short answer IMO is not to clone the manifest but have only one in the package along with a set of localization configurations (.json files) in the 'i18n' folder of the same package. |
We analyzed potential solutions and tended to use a way similar to Android's string resources. In this way, string resources can be saved to the related files in the i18n directory. Developers can refer to a resource using some syntax. And the MiniApp processor performs the extraction of the string resources from the i18n file according to its configuration. |
Here is a preliminary proposal: w3c/miniapp-manifest#12 |
FYI - the Internationalization WG is developing some best practices related to the specification of manifest files: https://w3c.github.io/localizable-manifests/ |
In our teleconference of 2021-01-07, the Internationalization WG actioned me with filing an issue to track discussion of the "internationalization design and architecture of miniapp". In our review of your spec so far and our discussions on various issue threads, it isn't clear how app authors are supposed to create, package, and release apps that serve multiple languages/locales. Some authors may choose to release apps that support quite large numbers of languages. If manifests must be cloned per-language/locale or if information must be duplicated, the result can be brittle (requiring a lot of maintenance) or can bloat application size needlessly.
We also have multiple comments about bidi and language metadata support. We have separately actioned @xfq with organizing additional conversation.
The text was updated successfully, but these errors were encountered: