[Spanish] translations - introducing national varieties - please comment

[Karim Rahimpur]

Hi,

Spanish language differs quite a lot in different countries and some
translations that are common in one country are meaningless or even
ridiculous in another. So having only "es" translations makes it
impossible to satisfy everyone.

My proposal is to add "es_ES" translations and that other "es" based
languages add their own translations in a similar manner when needed.

I would supply all *Labels.xml files as well as conditional.xml updated
so that each definition for "es" would be immediately followed by an
identical "es_ES" definition.

If anyone is interested to have their national variety included we could
add that in the same patch. The patch would then be supplied against the
most recent trunk revision so that it can be included easily.

My question is if there are any objections against this approach,
otherwise I would create a Jira issue when ready.

Anyone interested, please comment.

[Manuel Desdin]

agree totally,
but the person that did current spanish translation for ofbiz, please  
tell us where you are from, so we can put your country as the current  
spanish flavor. current translation is not spanish from spain!
thanks, manuel.

On 30 Jan 2009, at 11:39, Karim Rahimpur wrote:

> Hi,
>
> Spanish language differs quite a lot in different countries and some  
> translations that are common in one country are meaningless or even  
> ridiculous in another. So having only "es" translations makes it  
> impossible to satisfy everyone.
>
> My proposal is to add "es_ES" translations and that other "es" based  
> languages add their own translations in a similar manner when needed.
>
> I would supply all *Labels.xml files as well as conditional.xml  
> updated so that each definition for "es" would be immediately  
> followed by an identical "es_ES" definition.
>
> If anyone is interested to have their national variety included we  
> could add that in the same patch. The patch would then be supplied  
> against the most recent trunk revision so that it can be included  
> easily.
>
> My question is if there are any objections against this approach,  
> otherwise I would create a Jira issue when ready.
>
> Anyone interested, please comment.
>

[Karim Rahimpur]

Hi Manuel,

Thanks for your comment. I assume that the current spanish translation
is more a result of the community translating and think that's the
reason why the current isn't really spanish from Spain. I've already
made an effort to adjust those but instead of trying to make "es" fit
for everyone, introducing the national varieties would give all an
opportunity to have fitting translations for their own, also easier to
maintain. Anyhow, let's see if there are more opinions and then proceed.

Regards,
Karim

Manuel Desdin wrote:

> agree totally,
> but the person that did current spanish translation for ofbiz, please
> tell us where you are from, so we can put your country as the current
> spanish flavor. current translation is not spanish from spain!
> thanks, manuel.
>
> On 30 Jan 2009, at 11:39, Karim Rahimpur wrote:
>
>> Hi,
>>
>> Spanish language differs quite a lot in different countries and some
>> translations that are common in one country are meaningless or even
>> ridiculous in another. So having only "es" translations makes it
>> impossible to satisfy everyone.
>>
>> My proposal is to add "es_ES" translations and that other "es" based
>> languages add their own translations in a similar manner when needed.
>>
>> I would supply all *Labels.xml files as well as conditional.xml
>> updated so that each definition for "es" would be immediately
>> followed by an identical "es_ES" definition.
>>
>> If anyone is interested to have their national variety included we
>> could add that in the same patch. The patch would then be supplied
>> against the most recent trunk revision so that it can be included
>> easily.
>>
>> My question is if there are any objections against this approach,
>> otherwise I would create a Jira issue when ready.
>>
>> Anyone interested, please comment.
>>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.10.16/1925 - Release Date: 30/01/2009 7:37
>
>  

[Sven Wesley]

...and when talking about languages, why not moving to the more standardized
Java way of handling languages in language property files instead of XML?
For example ResourceBundleEditor, a Eclipse plugin, is a very great tool for
editing languages. Lang-properties are way easier to edit than XML-files in
my opinion (even if you're a manual-edit-wannabe).

Regards,
Sven

2009/1/30 Karim Rahimpur <[hidden email]>

> Hi Manuel,
>
> Thanks for your comment. I assume that the current spanish translation is
> more a result of the community translating and think that's the reason why
> the current isn't really spanish from Spain. I've already made an effort to
> adjust those but instead of trying to make "es" fit for everyone,
> introducing the national varieties would give all an opportunity to have
> fitting translations for their own, also easier to maintain. Anyhow, let's
> see if there are more opinions and then proceed.
>
> Regards,
> Karim
>
> Manuel Desdin wrote:
>
>> agree totally,
>> but the person that did current spanish translation for ofbiz, please tell
>> us where you are from, so we can put your country as the current spanish
>> flavor. current translation is not spanish from spain!
>> thanks, manuel.
>>
>> On 30 Jan 2009, at 11:39, Karim Rahimpur wrote:
>>
>>  Hi,
>>>
>>> Spanish language differs quite a lot in different countries and some
>>> translations that are common in one country are meaningless or even
>>> ridiculous in another. So having only "es" translations makes it impossible
>>> to satisfy everyone.
>>>
>>> My proposal is to add "es_ES" translations and that other "es" based
>>> languages add their own translations in a similar manner when needed.
>>>
>>> I would supply all *Labels.xml files as well as conditional.xml updated
>>> so that each definition for "es" would be immediately followed by an
>>> identical "es_ES" definition.
>>>
>>> If anyone is interested to have their national variety included we could
>>> add that in the same patch. The patch would then be supplied against the
>>> most recent trunk revision so that it can be included easily.
>>>
>>> My question is if there are any objections against this approach,
>>> otherwise I would create a Jira issue when ready.
>>>
>>> Anyone interested, please comment.
>>>
>>>  ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database:
>> 270.10.16/1925 - Release Date: 30/01/2009 7:37
>>
>>
>>
>

[Jeroen van der Wal-2]

I agree with you for having translations in separate files. To overcome this
drawback we wrote some tooling to export the xml files to separate gettext
files and merge them back in after translation (
https://issues.apache.org/jira/browse/OFBIZ-2008). There are a lot of tools
to edit gettext files, even an Eclipse plugin. It should however not be too
difficult to extend the code to use property files.

-Jeroen

On Fri, Jan 30, 2009 at 3:48 PM, Sven Wesley <[hidden email]> wrote:

> ...and when talking about languages, why not moving to the more
> standardized
> Java way of handling languages in language property files instead of XML?
> For example ResourceBundleEditor, a Eclipse plugin, is a very great tool
> for
> editing languages. Lang-properties are way easier to edit than XML-files in
> my opinion (even if you're a manual-edit-wannabe).
>
> Regards,
> Sven
>
> 2009/1/30 Karim Rahimpur <[hidden email]>
>
> > Hi Manuel,
> >
> > Thanks for your comment. I assume that the current spanish translation is
> > more a result of the community translating and think that's the reason
> why
> > the current isn't really spanish from Spain. I've already made an effort
> to
> > adjust those but instead of trying to make "es" fit for everyone,
> > introducing the national varieties would give all an opportunity to have
> > fitting translations for their own, also easier to maintain. Anyhow,
> let's
> > see if there are more opinions and then proceed.
> >
> > Regards,
> > Karim
> >
> > Manuel Desdin wrote:
> >
> >> agree totally,
> >> but the person that did current spanish translation for ofbiz, please
> tell
> >> us where you are from, so we can put your country as the current spanish
> >> flavor. current translation is not spanish from spain!
> >> thanks, manuel.
> >>
> >> On 30 Jan 2009, at 11:39, Karim Rahimpur wrote:
> >>
> >>  Hi,
> >>>
> >>> Spanish language differs quite a lot in different countries and some
> >>> translations that are common in one country are meaningless or even
> >>> ridiculous in another. So having only "es" translations makes it
> impossible
> >>> to satisfy everyone.
> >>>
> >>> My proposal is to add "es_ES" translations and that other "es" based
> >>> languages add their own translations in a similar manner when needed.
> >>>
> >>> I would supply all *Labels.xml files as well as conditional.xml updated
> >>> so that each definition for "es" would be immediately followed by an
> >>> identical "es_ES" definition.
> >>>
> >>> If anyone is interested to have their national variety included we
> could
> >>> add that in the same patch. The patch would then be supplied against
> the
> >>> most recent trunk revision so that it can be included easily.
> >>>
> >>> My question is if there are any objections against this approach,
> >>> otherwise I would create a Jira issue when ready.
> >>>
> >>> Anyone interested, please comment.
> >>>
> >>>
>  ------------------------------------------------------------------------
> >>
> >>
> >> No virus found in this incoming message.
> >> Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database:
> >> 270.10.16/1925 - Release Date: 30/01/2009 7:37
> >>
> >>
> >>
> >
>

[Jacques Le Roux]

No way, look into this thread for history please...

Jacques

From: "Jeroen van der Wal" <[hidden email]>
To: <[hidden email]>
Sent: Friday, January 30, 2009 4:07 PM
Subject: Re: [Spanish] translations - introducing national varieties - please comment

>I agree with you for having translations in separate files. To overcome this
> drawback we wrote some tooling to export the xml files to separate gettext
> files and merge them back in after translation (
> https://issues.apache.org/jira/browse/OFBIZ-2008). There are a lot of tools
> to edit gettext files, even an Eclipse plugin. It should however not be too
> difficult to extend the code to use property files.
>
> -Jeroen
>
> On Fri, Jan 30, 2009 at 3:48 PM, Sven Wesley <[hidden email]> wrote:
>
>> ...and when talking about languages, why not moving to the more
>> standardized
>> Java way of handling languages in language property files instead of XML?
>> For example ResourceBundleEditor, a Eclipse plugin, is a very great tool
>> for
>> editing languages. Lang-properties are way easier to edit than XML-files in
>> my opinion (even if you're a manual-edit-wannabe).
>>
>> Regards,
>> Sven
>>
>> 2009/1/30 Karim Rahimpur <[hidden email]>
>>
>> > Hi Manuel,
>> >
>> > Thanks for your comment. I assume that the current spanish translation is
>> > more a result of the community translating and think that's the reason
>> why
>> > the current isn't really spanish from Spain. I've already made an effort
>> to
>> > adjust those but instead of trying to make "es" fit for everyone,
>> > introducing the national varieties would give all an opportunity to have
>> > fitting translations for their own, also easier to maintain. Anyhow,
>> let's
>> > see if there are more opinions and then proceed.
>> >
>> > Regards,
>> > Karim
>> >
>> > Manuel Desdin wrote:
>> >
>> >> agree totally,
>> >> but the person that did current spanish translation for ofbiz, please
>> tell
>> >> us where you are from, so we can put your country as the current spanish
>> >> flavor. current translation is not spanish from spain!
>> >> thanks, manuel.
>> >>
>> >> On 30 Jan 2009, at 11:39, Karim Rahimpur wrote:
>> >>
>> >>  Hi,
>> >>>
>> >>> Spanish language differs quite a lot in different countries and some
>> >>> translations that are common in one country are meaningless or even
>> >>> ridiculous in another. So having only "es" translations makes it
>> impossible
>> >>> to satisfy everyone.
>> >>>
>> >>> My proposal is to add "es_ES" translations and that other "es" based
>> >>> languages add their own translations in a similar manner when needed.
>> >>>
>> >>> I would supply all *Labels.xml files as well as conditional.xml updated
>> >>> so that each definition for "es" would be immediately followed by an
>> >>> identical "es_ES" definition.
>> >>>
>> >>> If anyone is interested to have their national variety included we
>> could
>> >>> add that in the same patch. The patch would then be supplied against
>> the
>> >>> most recent trunk revision so that it can be included easily.
>> >>>
>> >>> My question is if there are any objections against this approach,
>> >>> otherwise I would create a Jira issue when ready.
>> >>>
>> >>> Anyone interested, please comment.
>> >>>
>> >>>
>>  ------------------------------------------------------------------------
>> >>
>> >>
>> >> No virus found in this incoming message.
>> >> Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database:
>> >> 270.10.16/1925 - Release Date: 30/01/2009 7:37
>> >>
>> >>
>> >>
>> >
>>
>

[Adrian Crum]

"es_ES" is not a valid locale ID. Spain Spanish is simply es. There are
locale IDs for different dialects of Spanish. You can look at the locale
selection screen page source to see the valid locale IDs.

-Adrian


Karim Rahimpur wrote:

> Hi,
>
> Spanish language differs quite a lot in different countries and some
> translations that are common in one country are meaningless or even
> ridiculous in another. So having only "es" translations makes it
> impossible to satisfy everyone.
>
> My proposal is to add "es_ES" translations and that other "es" based
> languages add their own translations in a similar manner when needed.
>
> I would supply all *Labels.xml files as well as conditional.xml updated
> so that each definition for "es" would be immediately followed by an
> identical "es_ES" definition.
>
> If anyone is interested to have their national variety included we could
> add that in the same patch. The patch would then be supplied against the
> most recent trunk revision so that it can be included easily.
>
> My question is if there are any objections against this approach,
> otherwise I would create a Jira issue when ready.
>
> Anyone interested, please comment.
>
>

[Adrian Crum]

Oops, I was wrong - "es_ES" IS a valid locale ID. I didn't see it at
first. I apologize for the confusion.

-Adrian

Adrian Crum wrote:

> "es_ES" is not a valid locale ID. Spain Spanish is simply es. There are
> locale IDs for different dialects of Spanish. You can look at the locale
> selection screen page source to see the valid locale IDs.
>
> -Adrian
>
>
> Karim Rahimpur wrote:
>> Hi,
>>
>> Spanish language differs quite a lot in different countries and some
>> translations that are common in one country are meaningless or even
>> ridiculous in another. So having only "es" translations makes it
>> impossible to satisfy everyone.
>>
>> My proposal is to add "es_ES" translations and that other "es" based
>> languages add their own translations in a similar manner when needed.
>>
>> I would supply all *Labels.xml files as well as conditional.xml
>> updated so that each definition for "es" would be immediately followed
>> by an identical "es_ES" definition.
>>
>> If anyone is interested to have their national variety included we
>> could add that in the same patch. The patch would then be supplied
>> against the most recent trunk revision so that it can be included easily.
>>
>> My question is if there are any objections against this approach,
>> otherwise I would create a Jira issue when ready.
>>
>> Anyone interested, please comment.
>>
>>
>

[Karim Rahimpur]

Hi Adrian,
That's ok, thanks for your input anyway.
Regards,
Karim

Adrian Crum wrote:

> Oops, I was wrong - "es_ES" IS a valid locale ID. I didn't see it at
> first. I apologize for the confusion.
>
> -Adrian
>
> Adrian Crum wrote:
>> "es_ES" is not a valid locale ID. Spain Spanish is simply es. There
>> are locale IDs for different dialects of Spanish. You can look at the
>> locale selection screen page source to see the valid locale IDs.
>>
>> -Adrian
>>
>>
>> Karim Rahimpur wrote:
>>> Hi,
>>>
>>> Spanish language differs quite a lot in different countries and some
>>> translations that are common in one country are meaningless or even
>>> ridiculous in another. So having only "es" translations makes it
>>> impossible to satisfy everyone.
>>>
>>> My proposal is to add "es_ES" translations and that other "es" based
>>> languages add their own translations in a similar manner when needed.
>>>
>>> I would supply all *Labels.xml files as well as conditional.xml
>>> updated so that each definition for "es" would be immediately
>>> followed by an identical "es_ES" definition.
>>>
>>> If anyone is interested to have their national variety included we
>>> could add that in the same patch. The patch would then be supplied
>>> against the most recent trunk revision so that it can be included
>>> easily.
>>>
>>> My question is if there are any objections against this approach,
>>> otherwise I would create a Jira issue when ready.
>>>
>>> Anyone interested, please comment.
>>>
>>>
>>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.233 / Virus Database: 270.10.16/1928 - Release Date: 31/01/2009 20:03
>
>  

[Bilgin Ibryam]

Hi devs,

I noticed that convertUom service accept Double and returns Double  
value(and it is correct as UomConversation.conversationFactor is with  
type Double). But all the code using convertUom service is already  
using BigDecimals and not working.

The solution seems to be to convert BigDecimals to Double before  
invoking convertUom, and then convert the Double from result to  
BigDecimal...

But, I wanted to ask is it a good idea to add also optional BigDecimal  
INOUT parameter to convertUom service so we can use it directly with  
BigDecimals?

Bilgin

[David E Jones-3]

Actually (IMO) we should change the service to not use Double at all  
and instead always use BigDecimal. It causes problems to use Double  
for calculations on BigDecimal numbers, but it is okay to use  
BigDecimal on Double numbers in any case we're likely to run into.

Is this something you're working on? If so, that's great...

-David


On Feb 1, 2009, at 9:43 AM, Bilgin Ibryam wrote:

> Hi devs,
>
> I noticed that convertUom service accept Double and returns Double  
> value(and it is correct as UomConversation.conversationFactor is  
> with type Double). But all the code using convertUom service is  
> already using BigDecimals and not working.
>
> The solution seems to be to convert BigDecimals to Double before  
> invoking convertUom, and then convert the Double from result to  
> BigDecimal...
>
> But, I wanted to ask is it a good idea to add also optional  
> BigDecimal INOUT parameter to convertUom service so we can use it  
> directly with BigDecimals?
>
> Bilgin

[Bilgin Ibryam]

Thanks for the advice David, it seems even easier:
Then I will change originalValue and convertedValue fields from Double  
to BigDecimal in convertUom and convertUomCustom. Is it what you had  
in mind ?


On Feb 1, 2009, at 7:53 PM, David E Jones wrote:

>
> Actually (IMO) we should change the service to not use Double at all  
> and instead always use BigDecimal. It causes problems to use Double  
> for calculations on BigDecimal numbers, but it is okay to use  
> BigDecimal on Double numbers in any case we're likely to run into.
>
> Is this something you're working on? If so, that's great...
>
> -David
>
>
> On Feb 1, 2009, at 9:43 AM, Bilgin Ibryam wrote:
>
>> Hi devs,
>>
>> I noticed that convertUom service accept Double and returns Double  
>> value(and it is correct as UomConversation.conversationFactor is  
>> with type Double). But all the code using convertUom service is  
>> already using BigDecimals and not working.
>>
>> The solution seems to be to convert BigDecimals to Double before  
>> invoking convertUom, and then convert the Double from result to  
>> BigDecimal...
>>
>> But, I wanted to ask is it a good idea to add also optional  
>> BigDecimal INOUT parameter to convertUom service so we can use it  
>> directly with BigDecimals?
>>
>> Bilgin
>

[David E Jones-3]

Unless someone has objections, then yes, let's go for it. This is not  
backward compatible, but that is true of many of these Double-
 >BigDecimal changes and we've already discussed it.

-David


On Feb 1, 2009, at 10:33 AM, Bilgin Ibryam wrote:

> Thanks for the advice David, it seems even easier:
> Then I will change originalValue and convertedValue fields from  
> Double to BigDecimal in convertUom and convertUomCustom. Is it what  
> you had in mind ?
>
>
> On Feb 1, 2009, at 7:53 PM, David E Jones wrote:
>
>>
>> Actually (IMO) we should change the service to not use Double at  
>> all and instead always use BigDecimal. It causes problems to use  
>> Double for calculations on BigDecimal numbers, but it is okay to  
>> use BigDecimal on Double numbers in any case we're likely to run  
>> into.
>>
>> Is this something you're working on? If so, that's great...
>>
>> -David
>>
>>
>> On Feb 1, 2009, at 9:43 AM, Bilgin Ibryam wrote:
>>
>>> Hi devs,
>>>
>>> I noticed that convertUom service accept Double and returns Double  
>>> value(and it is correct as UomConversation.conversationFactor is  
>>> with type Double). But all the code using convertUom service is  
>>> already using BigDecimals and not working.
>>>
>>> The solution seems to be to convert BigDecimals to Double before  
>>> invoking convertUom, and then convert the Double from result to  
>>> BigDecimal...
>>>
>>> But, I wanted to ask is it a good idea to add also optional  
>>> BigDecimal INOUT parameter to convertUom service so we can use it  
>>> directly with BigDecimals?
>>>
>>> Bilgin
>>
>