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 <oli.sennhau...@fromdual.com>: > 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, > Oli > > -- > > FromDual - Independent and Professional MySQL Services. > > Oli Sennhauser CTO / Senior Consultant > Phone: +41 44 940 24 82 Mobile: +41 79 830 09 33 > oli.sennhau...@fromdual.com http://www.fromdual.com > Skype: fromdual Twitter: fromdual > > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > -- Laurent Destailleur (alias Eldy) ------------------------------------------------------------------------------------ Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/awstats_project
_______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
