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

I18N design/architecture unclear #149

Open
aphillips opened this issue Jan 9, 2021 · 6 comments
Open

I18N design/architecture unclear #149

aphillips opened this issue Jan 9, 2021 · 6 comments
Labels
i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. manifest packaging

Comments

@aphillips
Copy link

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.

@aphillips aphillips added the i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. label Jan 9, 2021
@zhangyongjing
Copy link
Contributor

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.

@xfq
Copy link
Member

xfq commented Jan 11, 2021

@MichaelWangzitao
Copy link

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.
This method is relatively elegant and easy to maintain and does not need to change the development way of PWA manifest.

@xfq
Copy link
Member

xfq commented Mar 9, 2021

Here is a preliminary proposal: w3c/miniapp-manifest#12

@xfq
Copy link
Member

xfq commented Jul 26, 2021

FYI - the Internationalization WG is developing some best practices related to the specification of manifest files: https://w3c.github.io/localizable-manifests/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. manifest packaging
Projects
None yet
Development

No branches or pull requests

4 participants