UI - Translations

Status	DONE
Impact	HIGH
Driver	@Alessandro Domanico
Approver	@Alessandro Domanico
Stakeholders	@Niccolò Pasquetto @Henrique de Almeida @Riccardo Costa
Informed	@Ilario Gavioli
Due date	Apr 30, 2020
Outcome	Option1: Separated bundles (using i18next react library for “ui”)

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

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

possibility to adopt different and more reliable translations formats

It’s a Standard

double maintainance until “gui” will be still included in the release packages

more resources on Transifex

Same translations files for both “gui” and “ui”

Only one set of resources on Transifex

Transifex can handle automatically only one repository (Pull Requests), so updating both components will require manual work or more advanced release scripts, unless we move bundles in a new repository

possibility to adopt different and more reliable translations formats

Integrated with Develpment

Dedicated SDK

double maintainance until “gui” will be still included in the release packages

more resources on Transifex

Estimated cost (on the acutal codebase)

LARGE

MEDIUM

LOW

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)