Download & Extend
Localization server » Issues

Translation inheritance

Posted by claudiu.cristea on October 19, 2009 at 1:38pm
Project:Localization server
Version:6.x-1.x-dev
Component:Code
Category:feature request
Priority:normal
Assigned:claudiu.cristea
Status:needs review

Issue Summary

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?
Login or register to post comments

Comments

#1

Posted by Gábor Hojtsy on October 19, 2009 at 1:45pm
Title:Romanian informal/colloquial translation» Branching a translation
Project:Drupal.org webmasters» Localization server
Version:<none>» 6.x-1.x-dev
Component:Localize.drupal.org» Code

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

Posted by claudiu.cristea on October 20, 2009 at 5:53pm
Assigned to:Anonymous» claudiu.cristea
Status:active» needs review

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:

  • DB/UI for branches. Add/Edit/Delete branches
  • Importing .po files into specific branch
  • Exporting to .po files from a specific branch with base branch fall-back

Things not covered yet:

  • Branch informations in Overview pages - translate/languages/[langcode]
  • Adapt UI for viewing (only the base is viewed) - translate/languages/[langcode]/view
  • Adapt UI for editing (only base can be edited) - translate/languages/[langcode]/edit. This needs to be discussed together with #563128: Rework the translation UI
  • Branches in filters
  • Extracting from packages... I didn't even manage to think on this!

I need a precise advice regarding permissions: l10n_community.module, function l10n_community_branch_access()

AttachmentSizeStatusTest resultOperations
l10n_server_branch-D6.patch34.41 KBIgnoredNoneNone

#3

Posted by claudiu.cristea on October 20, 2009 at 7:14pm

Some small fixes...

AttachmentSizeStatusTest resultOperations
l10n_server_branch-D6.patch34.51 KBIgnoredNoneNone

#4

Posted by claudiu.cristea on October 21, 2009 at 6:10am

Another fix in the patch existing features.

An imported translation must be marked as duplicate if:

  1. Match an existing translation from his branch

    2. OR

  2. Match an existing translation from Base branch (bid = 0)

We don't want to import translations in a specific branch that are already translated in the base branch.

AttachmentSizeStatusTest resultOperations
l10n_server_branch1-D6.patch35.66 KBIgnoredNoneNone

#5

Posted by Gábor Hojtsy on January 20, 2010 at 1:14pm

As you have probably noticed, user permissions import/export issues and the new UI patch got/gets higher priority over this one, since those are to the benefit of all language groups even without any need for branching translations. So unfortunately it looks unlikely that I can take a deeper look at this soon.

#6

Posted by claudiu.cristea on January 20, 2010 at 2:35pm

I understand this. Anyway I cannot go forward with this feature till the new UI will not be in place. The patch does not cover the UI interaction... It's only about the DB infrastructure, managing (add/edit/delete)... mostly back-end.

#7

Posted by Xano on June 8, 2010 at 1:13pm
Title:Branching a translation» Translation inheritance

Renaming the issue, because branching is something different than inheritance.

Gábor pointed me here after a small discussion on IRC. My 2 cents:

  1. We do not only have to be able to deal with 'dialects' (British English versus American English or Flemish versus Dutch) and formal or informal translations, but also with distributions. Open Atrium may need different translations, because their contexts differ from those in Drupal. This way we have translation packages that are named openatrium-en-gb or nl-flemish-informal, for instance.
  2. If we want managing translations to be easy and good from inside a Drupal installation we need a fixed, but flexible format for translation names, so code can automatically define the language to look for translations for. Take openatrium-nl-flemish for instance. openatrium is the distro, nl the language, flemish the 'dialect'. If a user installs another module, the code can look for a openatrium-nl-flemish translation, but fall back to openatrium-nl if it cannot find openatrium-nl-flemish. The format needs to be flexible for additions, like -informal.
  3. Importing translations to branches will become more difficult. A British English translation contains 80 strings that are fit for all English languages and 20 that contain British English, so you don't want to add all strings to "en-gb", because that will make maintenance a lot more difficult. We need a solution for this. This will probably only apply to contrib modules, which usually contain a lot less strings than core, so we may tailor a solution to dozens or hundreds of strings rather than thousands.
nobody click here