Translation inheritance

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.

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.

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.

Same issue goes for ex-Yugoslavia languages, where Croatian, Serbian (latinics), Montenegrin, Bosnian and Serbocroatian are very common, but due to obvious reasons have some differences which are often important to the natives. There being a well developed Croatian package would give a huge head-start for those who who want to get going with the other families.

In my humble opinion, already 5 different names and language codes for one language package would already be an improvement.

I for one once downloaded Croatian and replaced all hr (hrvatski, Croatian) into sh (Srpskohrvatski, Serbocroatian), but of course that won't do.

So just to give some more thumbs-up for this thread!

Same is valid for Latin American Spanish and Castillian Spanish (Spoken in Spain). Beside a clear vocabulary difference, most Latin Americans address each other with Usted / Ustedes while in Spain the Tu / Vosotros is used. I don't see anywhere the possibility to choose the Local dialect of Spanish, but I do see a lot of Latin Americanisms in the "es" translation, making it utterly formal and therefore almost useless i.m.h.o. Lifting therefore the priority.

What is the state of this for D7/D8, anyone knows?

Attached are a couple of rough drafts of how a UI could look like. I think I prefer the three column version, but it might demand a wide monitor to be OK.

If a translator has permissions to translate both parent and child language, I think it would be best if he or she can translate both from the same page: When you're adapting for a variant, you might see strings to add or improve for the parent language as well. Would this be easy or hard to implement?

(Edited to change "she" to "he and she", to avoid confusion, after email question.)

Hi, have you also considered the scenario where the child language is in fact more developed than the parent, for example Croatian (as a well developed child) for parent Serbocroatian (which would also be the parent for Bosnian, Serbian (Latinic) Montenegrin and I'm sure I'm forgetting one)...

Related issue (possibly duplicate?): #1943782: Translation inheritance for common translations

I was looking for informal German translations and ended up here. This feature would be a great addition! Let's get this discussion started again!

So what is still missing here? As far as I can tell the proposed backend changes are loosely reviewed and agreed upon.

Backend

• Port existing code to 7.x (or is the 7.x skipped entirely?)
• Test coverage

Frontend

• Adapt UI for editing
• Branch informations in Overview pages - translate/languages/[langcode]
• Adapt UI for viewing (only the base is viewed) - translate/languages/[langcode]/view
• Branches in filters
• Extracting from packages
• Test coverage

Personally I would go for the 3 column layout as proposed, although there is currently not enough space as the website layout is fixed-width.

I would also try to have incremential updates and not try to integrate everything in one release, as this will take ages. E.g. comment #13 or fineer-grained permissions can be addressed once the main feature is functional.

@claudiu.cristea

Hi! I am wanting to work on translation inheritance to try and move this forward. Since you say the patch from D6 implements inheritance in the backend I am guessing you have some idea how the backend works.

Where is the inheritance happening is this on localize.drupal.org or is this on the drupal site where it is installed?

Or to put it another way, if a site wants to use a language derivative will they need to download the original language and the derivative?
Or will the derivative language be packaged in such a way that translations from the derivative plus translations from the original language are all in one package or will be downloaded automatically?

The reason I ask this is, some where for each derivative language there will need to be a configuration for inheritance. Will this be done on localize.drupal.org or will this be done on the site where drupal and the derivative translation is installed?

I picture this configuration for inheritance to look and function similar to the current multi language configuration in Drupal.

Thanks in advance for your insight into the backend for inheritance!

God Bless!
Frederick

Drupal 7 already has https://www.drupal.org/project/language_fallback and https://www.drupal.org/project/language_hierarchy and Drupal 8 has the backend features of language_fallback built in without a configurable frontend. So that could reproduce a configured language fallback system. I can see a way for localize.drupal.org and Drupal to replicate the same fallback configuration so they only need to share the different translation strings not copies.

#20: +1 for this and keep translatios DRY.
So i don't see any hurdle for starting de-informal #608488: Translation inheritance.
Memo to mee: talk this over with some people.

Note that this also goes for Dutch (u, je). The Dutch styleguide team suggests using the formal form so we need a way to allow the informal form (nl-x-informal?).

Also note that the German team decided to try to avoid the issue by skipping Du/Sie in translations. source: Nico Grienauer on Slack:

Nico Grienauer @grienauer
decision was do hae no du/sie and write texts without it.
if you want it, you have to translate the strings you want e.g. via UI. there is no du/Sie for D8!

What work still needs to be done to support nl-x-informal on ldo?