[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] Question/discussion about language translation

From: Destailleur Laurent
Subject: Re: [Dolibarr-dev] Question/discussion about language translation
Date: Mon, 12 May 2014 01:40:24 +0200

What you ask is already what it is.

the "en_US" language is master. This language is edited into github.
the "de_DE" contains all entries because all keys must be translated. I called this a primary language. Such languages are edited into "transifex".
the "de_CH" is a "secondary" language and only delta must be done. This is done by edited languages files (and only files with changes into github). Also only lines with difference must be into files.
Dolibarr is able to manage this. So this means this is already implemented (since several month i think).

However, for historical reason, the de_AT was done with "duplicate" of de_DE. So, conclusion is that files of de_AT contains more than they should and they can be cleaned to contains only delta. Everything should works.

2014-05-11 18:31 GMT+02:00 Oli Sennhauser <address@hidden>:
Hello all

as far as I have understood the language translation we have a default (en) and if you have configured your own language it will choose from there translation if exists.

For every sub-type of language which exists there is an own translation file (de_AT, de_DE, de_CH, ...).

And every sub-type of language contains the whole set of translations with probably 99% redundancy. This leads to a lot of redundant data and is very very error prone if somebody want to fix or improve stuff in the language.

Would it be possible and/or wishable that one has a 3-level inheritence of translation files?

For example: en -> de -> de_CH

If you do not find anything in de_CH (0.5% of data), use it in de (where 98.5% of data should reside) if not available use it in en (should only happen in less than 1% of the cases in a perfect world).

I think I found already some parts between de_DE and de_AT where it was diverging and in my language de_CH we name some things differently than in de_DE and de_AT so it will be even worse over time...

Please let me know your thoughts:

* if this is possible to implement and maintain
* if this is wish-able

If we agree that it is a good idea I look at the code to see how to implemented it.

Best Regards,


FromDual - Independent and Professional MySQL Services.

Oli Sennhauser                    CTO / Senior Consultant
Phone: +41 44 940 24 82           Mobile: +41 79 830 09 33
Skype: fromdual                   Twitter: fromdual

Dolibarr-dev mailing list

Laurent Destailleur (alias Eldy)
Social networks of my OpenSource projects:
Dolibarr Google+:
Dolibarr Facebook:
Dolibarr Twitter:
AWStats Google+:
AWStats Facebook:
AWStats Twitter:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]