...
| 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).
The aim is of course to recycle, if possible, the actual transaltions.
...
Relevant data
.properties files are used by the GUI
.csv files are used by the SQL scripts for the initial DB setup
.csv are hosted as .xlsx in Transifex and their management is manual at the moment (no GitHub-Transifex integration)
Transifex Native
In June 2020 has been announced a new possible workflow: Transifex Native.
The system allows to embed in the code the translation process through the provided Transifex SDK
...
This sure it is an interesting possibility, but it implies that we maintain two different projects in Transifex (until “gui” will be up and running), also because Transifex can handle automatically only one GitHub repository per project, so unless all the translation rely on a separated repo, we would not be able to update both (“gui” and “ui”). Moreover, it is not yet clear if the actual “gui” bundles (language_xx.properties) can be used “as is” in a React project like “ui”.
Options considered
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) |
|
|
|
Action 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)