...
| Page Properties | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||
|
Background
At the moment the Swing GUI translations are provided as .properties and .csv files in the project’s bundle/ subfolder. These files are also hosted on Transifex platform for the community contribution. Thanks to the GitHub-Transifex integration, new strings are automatically uploaded to Transifex and 100% translations are pushed back to GitHub (via PullRequest).
...
Option 1: Separated bundles | Option 2: Same bundles | Option 3: Transifex Native | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description | Separated Translation files between “gui” and “ui” | Same translation files | Indipendent System for “ui” | ||||||||||||||||||
Pros and cons |
|
|
| ||||||||||||||||||
Estimated cost (on the acutal codebase) |
|
|
|
possibility to adopt different and more reliable translations formats
double maintainance until “gui” will be still included in the release packagesAction items
- To define the localization pattern for the “ui” component
Outcome
Option1: Separated bundles (using i18next react library for “ui”)
After having tested different options, it turned out that Transifex Native technology was not fitting the need of offline translations as well as using the same “gui” technology (.properties files).
A more robust implementation will be achieved with a React library (i18next) and the related resources included in the Transifex workflow (new project OpenHoupital UI)