Redmine

1. Background

While updating the Swedish translation for 6.0, 6.1, 7.0 and trunk, I found that every release ships with strings that are still in English, because new keys are added to `en.yml` and the other locales only catch up when someone notices. For Swedish it was about 9 strings in 6.0, 37 in 6.1 and 71 in 7.0. The editor toolbar is worse: in 7.0.2, "Table" is still in English in 36 of 47 non-English toolbar files, and "Highlighted code" in 30.

The gaps are not caused by a lack of willing translators. They come from how translations are stored:

• Strings live in static files that only a developer can change, and a translator only sees a gap after a release is out.
• A language has to be maintained in two places: `config/locales/<lang>.yml` and `app/assets/javascripts/jstoolbar/lang/jstoolbar-<lang>.js`.
• There is no way to tell a missing translation from a correct one that happens to be identical to English ("Status", "Version", "Wiki", "Total").
• When an English string changes meaning, the translation is either left as it is, silently wrong, or reset to English.

Below is a suggestion for how this could work instead. It is meant as a starting point for discussion, not a finished design.

1. 1. One string register on top of the locale files

• The locale files stay as the shipped defaults.
• A register is layered on top of I18n and stored in the database, with an override per key and language.
• Core and plugins register their strings in the same place, instead of each plugin solving it separately.
• The toolbar strings move into the regular locale files and are handed to the toolbar from the server, so a language is translated in one place.

1. 2. Translation coverage per language

• An administration page shows, per language, how many strings are translated, missing or in need of review, for core and for each plugin.
• A string that is identical to English can be marked as translated. The mark is stored together with the English text it was made against.
• If the English text changes later, the mark no longer applies, and the string shows up as "needs review" instead of "translated". The same applies to every translated string, not only the identical ones, so a translation that has drifted from a changed English text is found too.

1. 3. Fix locally, export upstream

• A missing or wrong string can be fixed in a running instance and takes effect there directly.
• The fixes can be exported as a patch against `config/locales/<lang>.yml` (and the toolbar file, as long as it exists), ready to attach to an issue here.
• That turns every instance with an active translator into a source of complete, tested translations for the next release.

1. 4. Edit where the string is shown

• A user with a "manage translations" permission (not necessarily an administrator) holds a modifier key and sees a small icon next to every string that can be edited.
• A click opens the string in the register, with the English text, the current translation and its history.

1. 5. Copy and paste round trip

• The current state of a language can be exported as YAML, handed to a translator (a person or a machine translation service), and pasted back.
• Only missing and updated strings are picked up; nothing else is touched.

1. 6. Configurable data can be translated too

• Trackers, statuses, priorities, custom field names and list values can be given a translation per language, not only the shipped interface.
• Text written by people (issues, notes, wiki pages) is never translated.
• Translating is always possible and never required.

1. 7. Changes are tracked

• Every change records who made it, when, and the previous value.
• An override is never deleted, only replaced.
• A pure translation takes effect directly. A change to the original text or to a list value needs a reviewer, since it changes meaning for every language.

1. Questions to the core team

• Is a database layer on top of I18n acceptable in core, or should this stay a plugin with only the export format agreed upon?
• Would you accept patches generated this way, and in which format do you prefer them?
• Is moving the toolbar strings into the locale files something you would consider on its own, regardless of the rest?