[Trunk] Languaje es_XX should be extended to countries in latinoamerica

If it is approved, we make the compromise of copy all es_ES.po to es_XX.po to all localization has its own espanish thanks to Spain Team! ;-)
Venezuela, Colombia, Bolivia and Panama are mantained by us! ;-)

On Friday 15 October 2010, you wrote:
> If it is approved, we make the compromise of copy all es_ES.po to es_XX.po
> to all localization has its own espanish thanks to Spain Team! ;-)
> Venezuela, Colombia, Bolivia and Panama are mantained by us! ;-)

May I interrupt your joy and ask you to be careful in implementing that?

Having like 6x Spanish versions may mean more cost to maintain the Spanish
languages, effort multiplication for some things.

If you look at the code of language loading, there is a trivial algorithm that
would first try to load "es_MX" and if it doesn't exist, retry with "es".

So, my suggestion is to keep as much translations as possible under "es"
(things that can be common), and then only fork the modules that have a strict
terminology under the es_XX files.

[ Perhaps we could make some code to merge es => es_XX for parts of the
strings]

My humble opinion, as always.

It would be great to have translation "fallbacks".

I mean: When loading some languages like es_AR, OpenERP should first load es.po and then load es_AR.po.
Currently it only tries to load es_AR.po, that means that we have to duplicate all the translations each time we create one Spanish variant (and there are 22).
Like 95% of the terms on those countries are the same as the standard Spanish (es.po), so, having fallbacks would mean that we would only have to translate the 5% of terms that are different from the base language.

@xrg We can't just merge them all the "es_XX" as "es", the 5% of differences are words with important fiscal implications :(
They are also 'core' words: for example, the pickings are called in Spain "albarán", thats the only word used here, people won't call them any other way, but on some South-America variants of the Spanish they don't even know the word!

  * By the way, this is also true for other languages like Galician (gl_ES) or Catalonian (ca_ES), that would better fallback into Spanish that into English when a word is not translated. (Galician and Catalonian may share about a 25-50% of the words with Spanish!)

I agree with xrg. It is not necessary copy the es_ES.po to es_XX.po for a Spanish localization until a latinoamerica translation team has the need to adapt the translation of a specific module. In this way, if some of the latinoamerica teams are not very active, they will have more updated translations.

But the patch proposed by Nhomar is absolutely necessary to be able to do the latinoamerica translations of OpenERP. I have told to some latinoamerica members several times in the last months about asking to the official team to add their languages as Nhomar has done.

Hello Guys,

     IMHO it would not be feasible to first load es.po and then the es_XX.po files because we can have the overhead of having the same procedure two times. I'll suggest to have different es_XX.po files with 95% same translations along with 5% uncommon translations. By doing this we don't need to change the translation functionalities and it will take the same time as it takes to load a language right now. Your views.

Thanks.

Hello.

I think like Anup, (even the idea of load a first es.po sounds cool), we
have several priorities, and mantain several files is not a problem , but
develop the approach i thin can convert the translation in a problem for the
first release of V6, maybe for V8 this information should be more mature
anyway, but fo now with only the fact of have this countries that I propose
is enought, As I said, we can become this 5% is not a a herculian work ;-).

With only the fact of accept this others options that i proposed, it is
enought for us by now ;-)

Thanks Folks for give your opinions.

2010/10/15 Anup (OpenERP) <email address hidden>

> Hello Guys,
>
> IMHO it would not be feasible to first load es.po and then the
> es_XX.po files because we can have the overhead of having the same
> procedure two times. I'll suggest to have different es_XX.po files with
> 95% same translations along with 5% uncommon translations. By doing this
> we don't need to change the translation functionalities and it will take
> the same time as it takes to load a language right now. Your views.
>
> Thanks.
>
> --
> [Trunk] Languaje es_XX should be extended to countries in latinoamerica
> https://bugs.launchpad.net/bugs/660933
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenObject Server.
>
> Status in OpenObject Server: Confirmed
>
> Bug description:
> Hello.
>
> IMHO, we should count with the lenguages availables around all countries
> where there are community working around openERP, Spanish is speaked in
> almost 22 countries, not only Spain and Argentina (the last one has not done
> almost anything in them translation around the last 2 years.) but Spain yes.
>
> We are growing up quickly in LatinAmerica and we think as partners and
> community members that have available his own commercial lenguaje around
> OpenERP installes OutOfthebox should be very insteresting to incentivate
> several more instalations in LA.
>
> I propose a patch with countries where I know there are people working hard
> with community, and there are partners.
>
> Regards.
>
>
>

--
Saludos Cordiales

On Friday 15 October 2010, you wrote:
> Hello Guys,
>
> IMHO it would not be feasible to first load es.po and then the
> es_XX.po files because we can have the overhead of having the same
> procedure two times.

The overhead of loading the translation 2 times is not important, IMHO,
because that only happends during a DB upgrade, which is 5min every so many
months that you would keep the db.
But it just doesn't yet work that way. Currently, you cannot load both es.po
and es_XX.po for the same module.

What I said in the first place is to only have es_XX.po for those modules where
terms are different (eg. account, stock, purchase - perhaps), but keep only an
es.po for the modules that can share terms (eg. idea, lunch, wiki, event).
See?

Ok guys, you got me convinced: What @xrg proposes (es_XX.po only on modules that really require it) is what should be done for 6.0.

Anyway, for 6.X or 7.0, I would love to have an option to setup "fall-back languages". Does not look that hard to implement (maybe I give it a try) and would help a lot with languages with variants (Spanish, Portuguese), or languages that are similar to, or 'friendly' with, others.

Your final conclusions sound like the best solution for v6.0 (i.e. duplicate the es.po only for the few modules that require different terms).

For post-v6 we'll see if we can implement some sort of language inheritance or fallback mechanism (I put it in the product backlog for the server). However the main problem here is the fact that LP doesn't seem to support this concept, so Rosetta would still ask translators to translate 100% of the terms for es_CO for example (and as soon as we need to duplicate the strings in the .po files the maintenance issue appears)

Hello Oliver.

For us, with the only improvement of have es_XX available as i proposed in the patch on rosetta is enought for V6, we know than technically may fall-back can be a little difficult and It doesn't add value for now, we have several other priorities.

COnclusion, only apply the patch and please enable minimal es_XX please, when you can, we from netquatro can add all initial files to addons-extra, addons and server, I almost sure other people will be happy around this here in LA ;-)

Regards

Fix landed in revision 2924 rev-id: <email address hidden>

Thanks for reporting this Nhomar!

BTW I think I've seen some concept of default language on Rosetta, I'll investigate and we'll definitely consider this for 6.1 (I added it to product backlog)

Hello all,

Olivier, sorry, but I still don't understand why the famous "product
backlog" is hidden in the dark instead of published somewhere...

On Wed, Oct 20, 2010 at 3:05 PM, Olivier Dony (OpenERP) <
<email address hidden>> wrote:

> Thanks for reporting this Nhomar!
>
> BTW I think I've seen some concept of default language on Rosetta, I'll
> investigate and we'll definitely consider this for 6.1 (I added it to
> product backlog)
>
> --
> [Trunk] Languaje es_XX should be extended to countries in latinoamerica
> https://bugs.launchpad.net/bugs/660933
> You received this bug notification because you are subscribed to
> OpenObject Server.
>
> Status in OpenObject Server: Fix Released
>
> Bug description:
> Hello.
>
> IMHO, we should count with the lenguages availables around all countries
> where there are community working around openERP, Spanish is speaked in
> almost 22 countries, not only Spain and Argentina (the last one has not done
> almost anything in them translation around the last 2 years.) but Spain yes.
>
> We are growing up quickly in LatinAmerica and we think as partners and
> community members that have available his own commercial lenguaje around
> OpenERP installes OutOfthebox should be very insteresting to incentivate
> several more instalations in LA.
>
> I propose a patch with countries where I know there are people working hard
> with community, and there are partners.
>
> Regards.
>
>
>

It work very well for me, I didn't understand "product-backlog" neither as raphael said ;-)

BTW this is one of the bugs than i have been prouder to close ever....

Thanks a lot!

Don't say that es_AR hasn't been updated on 2 years. It's not true.