Branching a translation
| Project: | Localization server |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | claudiu.cristea |
| Status: | needs review |
As in German language, in Romanian there are two forms of addressing. While in English you use "You", in German you can use "Sie" (formal) or "Du" (informal, colloquial) and in Romanian "Dumneavoastră" (formal) or "Tu" (informal, colloquial). See http://drupal.org/project/de-informal.
Many users of Romanian translation have asked for an informal/colloquial version. For example, on an official site (company, public institution, ONG) you may want to use the formal form of addressing while on youth targeted site you may want to use the informal/colloquial translation...
While in drupal.org translations this seems to be something quite simple to achieve by creating and maintaining a separate branch in CVS for the Romanian translation, this seems to be difficult on localize.drupal.org.
It seems to be impossible without creating a new language (ro-informal or ro-colloquial) while we cannot define something like branches in a language. Moreover, creating a new language raise other issues:
- We need a single OG group handle both languages not two separate confusing groups.
- Maybe more than 50% of source strings will be the same. Maintaining them separately will lead to a loss of effort and to redundancy.
Finally, the questions are:
- Are there some similar cases?
- What are the best practices in cases like this?
- Can this be a start discussion for a new feature on Localization server while (I almost sure) that not only German and Romanian languages are facing this issue?
#1
Retitled to be more generic. Also, moved to l10n_server.
This came up a few times, and is indeed a drawback of the localization server. Theoretically branching languages could be supported by having "translation overrides", and a "base language", so a team can translate in a base language picking formal or informal for example and then branching to a different version. We might also need to support more then 2 branches (more then 1 language inheriting from one common base language), if we consider smaller regional variants of languages, etc.
#2
This is a first patch in this direction.
The patch only creates the infrastructure for branches in Localization server and doesn't provide any branched translation UI (in this moment).
Right now, it provides:
Things not covered yet:
translate/languages/[langcode]translate/languages/[langcode]/viewtranslate/languages/[langcode]/edit. This needs to be discussed together with #563128: Rework the translation UII need a precise advice regarding permissions:
l10n_community.module, functionl10n_community_branch_access()#3
Some small fixes...
#4
Another fix in the patch existing features.
An imported translation must be marked as duplicate if:
OR
We don't want to import translations in a specific branch that are already translated in the base branch.