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) | LARGE | MEDIUM | LOW |
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