Why not seperate language files?

[Vu Hong Thuan]

Hi devs,
Why not we seperate language files into each seperate language file.
Such as: workeffortuilabels.xml is seperated into workeffortuilabels.en.xml
or workeffortuilabels.fr.xml
There are some reasons for doing this:

1. Our applications only want to support a few of language
2. It's easier to create new file language separatly.
3. It maybe increase performent of all application in processing language
files.

Thanks.


--
Vũ Hồng Thuận
Công ty Phần mềm và Truyền thông Việt Nam, NAMMEDIA, INC.
Email: [hidden email]
Web: http://www.nammedia.com
ĐT: [phone] - Fax: [phone]
DĐ: [phone]

Vu Hong Thuan
Vietnam Software and Communication Company. NAMMEDIA. INC
Email: [hidden email]
Web: http://www.nammedia.com
Phone: [phone] - Fax: [phone]
Mobile: [phone]

[Vikas Mayur-3]

This method was used before with labels of different languages in a  
separate .properties file and has been deprecated.

Vikas

On Oct 27, 2008, at 10:08 PM, Vu Hong Thuan wrote:

> Hi devs,
> Why not we seperate language files into each seperate language file.
> Such as: workeffortuilabels.xml is seperated into  
> workeffortuilabels.en.xml
> or workeffortuilabels.fr.xml
> There are some reasons for doing this:
>
> 1. Our applications only want to support a few of language
> 2. It's easier to create new file language separatly.
> 3. It maybe increase performent of all application in processing  
> language
> files.
>
> Thanks.
>
>
> --
> Vũ Hồng Thuận
> Công ty Phần mềm và Truyền thông Việt Nam, NAMMEDIA, INC.
> Email: [hidden email]
> Web: http://www.nammedia.com
> ĐT: [phone] - Fax: [phone]
> DĐ: [phone]
>
> Vu Hong Thuan
> Vietnam Software and Communication Company. NAMMEDIA. INC
> Email: [hidden email]
> Web: http://www.nammedia.com
> Phone: [phone] - Fax: [phone]
> Mobile: [phone]

[Adrian Crum]

That was a design decision made some time ago. The OFBiz community
agreed that having all languages in a single file makes translation
easier and it also makes it easier to spot missing translated labels.

There is no performance penalty for having all translations in one file.
UI labels are kept in a memory cache.

The framework still supports separate language files. You can use both
formats together.

-Adrian

Vu Hong Thuan wrote:

> Hi devs,
> Why not we seperate language files into each seperate language file.
> Such as: workeffortuilabels.xml is seperated into workeffortuilabels.en.xml
> or workeffortuilabels.fr.xml
> There are some reasons for doing this:
>
> 1. Our applications only want to support a few of language
> 2. It's easier to create new file language separatly.
> 3. It maybe increase performent of all application in processing language
> files.
>
> Thanks.
>
>

[Vu Hong Thuan]

Thank for your reply.
How can I use a separate translated file?

2008/10/27 Adrian Crum <[hidden email]>

> That was a design decision made some time ago. The OFBiz community agreed
> that having all languages in a single file makes translation easier and it
> also makes it easier to spot missing translated labels.
>
> There is no performance penalty for having all translations in one file. UI
> labels are kept in a memory cache.
>
> The framework still supports separate language files. You can use both
> formats together.
>
> -Adrian
>
>
> Vu Hong Thuan wrote:
>
>> Hi devs,
>> Why not we seperate language files into each seperate language file.
>> Such as: workeffortuilabels.xml is seperated into
>> workeffortuilabels.en.xml
>> or workeffortuilabels.fr.xml
>> There are some reasons for doing this:
>>
>> 1. Our applications only want to support a few of language
>> 2. It's easier to create new file language separatly.
>> 3. It maybe increase performent of all application in processing language
>> files.
>>
>> Thanks.
>>
>>
>>

--
Vũ Hồng Thuận
Công ty Phần mềm và Truyền thông Việt Nam, NAMMEDIA, INC.
Email: [hidden email]
Web: http://www.nammedia.com
ĐT: [phone] - Fax: [phone]
DĐ: [phone]

Vu Hong Thuan
Vietnam Software and Communication Company. NAMMEDIA. INC
Email: [hidden email]
Web: http://www.nammedia.com
Phone: [phone] - Fax: [phone]
Mobile: [phone]

[Adrian Crum]

You can use a *.properties file, or a Java 5 XML properties file -
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html#loadFromXML(java.io.InputStream).

-Adrian


Vu Hong Thuan wrote:

> Thank for your reply.
> How can I use a separate translated file?
>
> 2008/10/27 Adrian Crum <[hidden email]>
>
>> That was a design decision made some time ago. The OFBiz community agreed
>> that having all languages in a single file makes translation easier and it
>> also makes it easier to spot missing translated labels.
>>
>> There is no performance penalty for having all translations in one file. UI
>> labels are kept in a memory cache.
>>
>> The framework still supports separate language files. You can use both
>> formats together.
>>
>> -Adrian
>>
>>
>> Vu Hong Thuan wrote:
>>
>>> Hi devs,
>>> Why not we seperate language files into each seperate language file.
>>> Such as: workeffortuilabels.xml is seperated into
>>> workeffortuilabels.en.xml
>>> or workeffortuilabels.fr.xml
>>> There are some reasons for doing this:
>>>
>>> 1. Our applications only want to support a few of language
>>> 2. It's easier to create new file language separatly.
>>> 3. It maybe increase performent of all application in processing language
>>> files.
>>>
>>> Thanks.
>>>
>>>
>>>
>
>

[Adam Heath-2]

Adrian Crum wrote:

> There is no performance penalty for having all translations in one file.
> UI labels are kept in a memory cache.

Bzzt, wrong, memory usage is a definate penalty.

[Adrian Crum]

*takes away Adam's buzzer*

Adam Heath wrote:
> Adrian Crum wrote:
>
>> There is no performance penalty for having all translations in one file.
>> UI labels are kept in a memory cache.
>
> Bzzt, wrong, memory usage is a definate penalty.
>

[David E Jones]

On Oct 27, 2008, at 12:53 PM, Adam Heath wrote:

> Adrian Crum wrote:
>
>> There is no performance penalty for having all translations in one  
>> file.
>> UI labels are kept in a memory cache.
>
> Bzzt, wrong, memory usage is a definate penalty.

I call shenanigans on this statement.

How is the memory footprint worse for one file versus many?

-David

[Adam Heath-2]

Adrian Crum wrote:
> *takes away Adam's buzzer*

Huh?  I mean seriously, huh?

[Adrian Crum]

FYI: our custom ResourceBundle class doesn't cache the entire file - it
only caches the requested locale(s) within the file.

And whether the requested labels came from a single file or our custom
XML file, they are all converted to a Properties object - so there
should be no difference in memory used.

-Adrian

David E Jones wrote:

>
> On Oct 27, 2008, at 12:53 PM, Adam Heath wrote:
>
>> Adrian Crum wrote:
>>
>>> There is no performance penalty for having all translations in one file.
>>> UI labels are kept in a memory cache.
>>
>> Bzzt, wrong, memory usage is a definate penalty.
>
> I call shenanigans on this statement.
>
> How is the memory footprint worse for one file versus many?
>
> -David
>
>

[Adam Heath-2]

David E Jones wrote:

>
> On Oct 27, 2008, at 12:53 PM, Adam Heath wrote:
>
>> Adrian Crum wrote:
>>
>>> There is no performance penalty for having all translations in one file.
>>> UI labels are kept in a memory cache.
>>
>> Bzzt, wrong, memory usage is a definate penalty.
>
> I call shenanigans on this statement.
>
> How is the memory footprint worse for one file versus many?

Go back to what was originally said; if a deployment will only ever use
a small subset of the languages available, then there is a memory hit
for storing those other unused languages.

[Adam Heath-2]

Adrian Crum wrote:
> FYI: our custom ResourceBundle class doesn't cache the entire file - it
> only caches the requested locale(s) within the file.
>
> And whether the requested labels came from a single file or our custom
> XML file, they are all converted to a Properties object - so there
> should be no difference in memory used.

Except that the shared character arrays inside the strings that are from
the parsed xml might be holding on to excess memory.

[Adrian Crum]

I wonder how that could be tested.

-Adrian

Adam Heath wrote:

> Adrian Crum wrote:
>> FYI: our custom ResourceBundle class doesn't cache the entire file - it
>> only caches the requested locale(s) within the file.
>>
>> And whether the requested labels came from a single file or our custom
>> XML file, they are all converted to a Properties object - so there
>> should be no difference in memory used.
>
> Except that the shared character arrays inside the strings that are from
> the parsed xml might be holding on to excess memory.
>

[Adam Heath-2]

Adrian Crum wrote:
> I wonder how that could be tested.

Go look into jhat and jconsole, and be sure to use java 1.6.  With java
1.6, you can attach jconsole to an already running java instance, and
get a binary memory dump.  Then, using jhat, you can, with much
diligence, drill down to find how large the character array is for a
particular string.

It's how I knew that doing String.intern() on the data read from the
entitymodel.xml files would be useful.  See svn version 585838.

[Adrian Crum]

I'll check into that - thanks!

In this case, should we take the shotgun approach and just use intern on
the custom XML properties files? Do you know of any disadvantage to
using intern too much?

-Adrian

Adam Heath wrote:

> Adrian Crum wrote:
>> I wonder how that could be tested.
>
> Go look into jhat and jconsole, and be sure to use java 1.6.  With java
> 1.6, you can attach jconsole to an already running java instance, and
> get a binary memory dump.  Then, using jhat, you can, with much
> diligence, drill down to find how large the character array is for a
> particular string.
>
> It's how I knew that doing String.intern() on the data read from the
> entitymodel.xml files would be useful.  See svn version 585838.
>

[Adam Heath-2]

Adrian Crum wrote:
> I'll check into that - thanks!
>
> In this case, should we take the shotgun approach and just use intern on
> the custom XML properties files? Do you know of any disadvantage to
> using intern too much?

The biggest issue one might face is that the memory might not be freed,
until *all* references to a single shared common word are freed.  But,
in that case, it can actually help with memory usage.

At parse time, there is the additional overhead of looking up the string
in the internal hashmap; but once loaded, things run faster; Comparing
interned strings is faster, as a quick == can be used.