History: Translation branching strategy

Here is the problem:

http://old.nabble.com/language.php%3A-trunk-versus-3.0-tt23746165.html

Problems

language.php: the strings are not all/always in the same order so merging can be a nightmare

Options

Translate to trunk, no automatic backport

Translators decide to backport to branch or not as they wish.

• If no backport, people have to wait next major version before using.

Why not: Translate to trunk, with backport to LTS?

• People would not have to wait for new version
• Just 1 translation branch (trunk) (no double work/translations)
• i18n server translations are made in trunk anyway (correct?)

Alternative to stable proposals

Quality Team needs to merge

Translate to stable branch, with merge up

• Who will run the script?

- script to run each time a branch is updated to become "version" (omstefanov)

• How to manage merge conflicts?

- give options (omstefanov):
1. replace stable with branch (complete table)
2. replace branch with stable (complete table)
3. merge, if duplicate source lang but variant target lang, branch overrides stable
4. merge, if duplicate source lang but variant target lang, stable overrides branch
5. produce list of variants. Assumes that merge can be run over and over again.
6. give users interactive possibilities to choose which variant to keep (usable only if not too many mismatches).

Alternative to stable proposals

Quality Team needs to merge

Suggestions

(Torsten)

Siteadmins could then backport their individual languages by themselves by just downloading and copying the language.php of one or a few languages into /lang/XYZ .

For certain custom translations this would anyway to be considered by an admin.
(for ex. for one of my sites "shoutbox" is "roadbook", what is very specific and not for the main codebase - I do have several translations like this)