iodide-project / iodide-project/iodide
Proposal of Internationalization Support for Iodide System
- Dominant language
- JavaScript
- Stars
- 1.5k
- Forks
- 145
- PR merge metrics
- No merged PRs in 30d
Description
# Internationalization Support for Iodide System
## Objective
This proposal lays down a guideline to internationalize Iodide system. It aims to make Iodide capable of serving system catered to the locale of the user, but it does not aim to make Iodide notebooks capable of serving content according to the locale of the user since that is a separate effort with separate concerns. Internationalization of dates, numbers, plurals, and text are the goals of this proposal, but besides those, there is the topic of appearance internationalization which consists of things like the right-to-left version of the system. For minimum viable product, this proposal does not consider the latter. Internationalization of documentation is a discussion question.
## Motivation
Iodide and the vision of it do not state any constraints its audience by background. However, given the ease of implementation today, not providing a system that could be navigated by people of different background is a constraint itself.
## User Benefit
Internationalization of system will help people of different background on their path to accessing notebooks. It can give both moral support to the user, helping them feel included, and usage support since many people find it more comfortable to work in their native languages.
## Related Work
It is possible to categorize related work into three categories: localized text as literal in code, separation of code and text, extraction of literals from code and separation to another file.
One can perceive these three as the evolution of internationalization systems too. At first, it is quick to hard code literals and switch based on locale selection. Then one would separate the literals from code to enable people with no programming experience to contribute. At last, literal extraction from code automatically would make it easier to code without giving much thought on localization files.
Although in ideal conditions literal extraction would be very beneficial, not putting any burden on developers of Iodide system itself, it is neither an easy task to achieve in the Javascript, Python ecosystem nor very needed given that Iodide already appropriately places displayed string literals such that they can easily integrate to an internationalization solution.
Since internationalization is more of a community sport, there is an ecosystem of platforms that make it easier for people with less development background to contribute to the translation of texts. In that area, Mozilla Pontoon and Project Fluent tick all boxes and work together well, with Firefox Send ( https://github.com/mozilla/send ) and Mozilla Common Voice ( https://github.com/mozilla/voice-web ) being good integration examples for Iodide. Project Fluent also provides Javascript implementation with React support and Python implementation.
## Design Proposal
### System
Mostly, the design consists of the integration of Pontoon and Fluent-js. Successful integration of both results in a system that correctly works with BCP-47 locale codes and contributable by the extended community, including those with no coding background.
#### Pontoon
Following documents are clear steps applicable to Iodide to integrate Pontoon:
- https://mozilla-pontoon.readthedocs.io/en/latest/user/localizing-your-projects.html
- https://mozilla-l10n.github.io/documentation/tools/pontoon/adding_new_project.html
#### Fluent-js
Since Mozilla Common Voice also utilizes React, it is logical to follow its implementation of Fluent-js. Iodide can host locale files in `iodide/server/static/locales/...` path with a custom generated `iodide/server/static/locales/locales.json` and statically serve them to resolve in client side.
### Documentation
Please look at "Questions and Discussion Topics" section.
## Questions and Discussion Topics
- How to integrate Pontoon into MkDocs? Since MkDocs does not provide an internal internationalization solution, custom integration is required. Does Iodide plan to stick with MkDocs?
- How to handle the fonts? Community is trying to move away from tofu boxes that replace unprovided characters.
- How to move forward with appearance internationalization?
- Are there any sentences or sentence groups that would benefit from further clarification in this proposal?
Contributor guide
Research direction
This is a broad design proposal rather than a scoped implementation task. Start by reviewing the proposed locale path `iodide/server/static/locales/...`, the generated `locales.json`, and the Pontoon and Fluent-js references; work is only ready when the integration scope, ownership, and acceptance criteria are agreed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- internationalization
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100