You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Karim Rahimpur <kr...@tamagos.com> on 2009/01/30 11:39:55 UTC
[Spanish] translations - introducing national varieties - please
comment
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.
Re: [Spanish] translations - introducing national varieties - please
comment
Posted by Karim Rahimpur <kr...@tamagos.com>.
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
>
>
Re: convertUom service and BigDecimals
Posted by David E Jones <da...@hotwaxmedia.com>.
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
>>
>
Re: convertUom service and BigDecimals
Posted by Bilgin Ibryam <bi...@iguanait.com>.
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
>
Re: convertUom service and BigDecimals
Posted by David E Jones <da...@hotwaxmedia.com>.
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
convertUom service and BigDecimals
Posted by Bilgin Ibryam <bi...@iguanait.com>.
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
Re: [Spanish] translations - introducing national varieties - please
comment
Posted by Adrian Crum <ad...@hlmksw.com>.
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.
>>
>>
>
Re: [Spanish] translations - introducing national varieties - please
comment
Posted by Adrian Crum <ad...@hlmksw.com>.
"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.
>
>
Re: [Spanish] translations - introducing national varieties - please comment
Posted by Jacques Le Roux <ja...@les7arts.com>.
No way, look into this thread for history please...
Jacques
From: "Jeroen van der Wal" <jv...@stromboli.it>
To: <de...@ofbiz.apache.org>
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 <sv...@gmail.com> 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 <kr...@tamagos.com>
>>
>> > 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
>> >>
>> >>
>> >>
>> >
>>
>
Re: [Spanish] translations - introducing national varieties - please
comment
Posted by Jeroen van der Wal <jv...@stromboli.it>.
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 <sv...@gmail.com> 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 <kr...@tamagos.com>
>
> > 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
> >>
> >>
> >>
> >
>
Re: [Spanish] translations - introducing national varieties - please
comment
Posted by Sven Wesley <sv...@gmail.com>.
...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 <kr...@tamagos.com>
> 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
>>
>>
>>
>
Re: [Spanish] translations - introducing national varieties - please
comment
Posted by Karim Rahimpur <kr...@tamagos.com>.
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
>
>
Re: [Spanish] translations - introducing national varieties - please comment
Posted by Manuel Desdin <md...@iguanait.com>.
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.
>