XML properties files - brainstorm

[Adrian Crum]

David Jones has suggested in the past that we start moving away from using properties files for UI
labels and such, and use XML files instead. That subject has come up again in
https://issues.apache.org/jira/browse/OFBIZ-1425.

I would be interested in helping out with the implementation, but I'd like to get input from the
developer community first.

-----

Here are some of the suggestions David made:

"If we do something like that, here or anywhere, we should use XML and not properties files. XML is
about 1E6 times better than properties files (name/value pairs) for organizing this sort of
information. It is hierarchical so much easier to organize and you can use real UTF-8 characters
there instead of having to encode everything and use a special tool or a translator to work on the
files."

and

"In XML there are standard ways of doing this, namely using the xml:lang attribute on an element to
specify the language of the content in an element."

-----

I have been thinking about this for a while, and I was picturing a refactoring of the resource
handling code so that it can read xml files in addition to *.properties files. The file format would
be invisible from a programmer's perspective. In other words, the method call
UtilProperties.getPropertyValue("SomeResource", "SomeProperty") would still work even if the
"SomeResource" resource was in an XML file.

Or we can just have a utility to retrieve resources from an XML file.

Regardless of how the properties are retrieved, we still need to come up with a strategy (or schema)
for the xml file format. I'm not an XML guru, so this is one area where I could use some help.

Do we continue to keep each language in a separate file or should we have all properties for all
languages in a single file?

Are there any other issues anyone can think of?

Comments welcome.

-Adrian

[Adrian Crum]

I found the answer to the XML file format - java.util.Properties already supports one:

http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html


Adrian Crum wrote:

> David Jones has suggested in the past that we start moving away from
> using properties files for UI labels and such, and use XML files
> instead. That subject has come up again in
> https://issues.apache.org/jira/browse/OFBIZ-1425.
>
> I would be interested in helping out with the implementation, but I'd
> like to get input from the developer community first.
>
> -----
>
> Here are some of the suggestions David made:
>
> "If we do something like that, here or anywhere, we should use XML and
> not properties files. XML is about 1E6 times better than properties
> files (name/value pairs) for organizing this sort of information. It is
> hierarchical so much easier to organize and you can use real UTF-8
> characters there instead of having to encode everything and use a
> special tool or a translator to work on the files."
>
> and
>
> "In XML there are standard ways of doing this, namely using the xml:lang
> attribute on an element to specify the language of the content in an
> element."
>
> -----
>
> I have been thinking about this for a while, and I was picturing a
> refactoring of the resource handling code so that it can read xml files
> in addition to *.properties files. The file format would be invisible
> from a programmer's perspective. In other words, the method call
> UtilProperties.getPropertyValue("SomeResource", "SomeProperty") would
> still work even if the "SomeResource" resource was in an XML file.
>
> Or we can just have a utility to retrieve resources from an XML file.
>
> Regardless of how the properties are retrieved, we still need to come up
> with a strategy (or schema) for the xml file format. I'm not an XML
> guru, so this is one area where I could use some help.
>
> Do we continue to keep each language in a separate file or should we
> have all properties for all languages in a single file?
>
> Are there any other issues anyone can think of?
>
> Comments welcome.
>
> -Adrian
>
>
>

[David E Jones]

On Nov 26, 2007, at 11:10 AM, Adrian Crum wrote:

> David Jones has suggested in the past that we start moving away from  
> using properties files for UI labels and such, and use XML files  
> instead. That subject has come up again in https://issues.apache.org/jira/browse/OFBIZ-1425 
> .
>
> I would be interested in helping out with the implementation, but  
> I'd like to get input from the developer community first.
>
> -----
>
> Here are some of the suggestions David made:
>
> "If we do something like that, here or anywhere, we should use XML  
> and not properties files. XML is about 1E6 times better than  
> properties files (name/value pairs) for organizing this sort of  
> information. It is hierarchical so much easier to organize and you  
> can use real UTF-8 characters there instead of having to encode  
> everything and use a special tool or a translator to work on the  
> files."
>
> and
>
> "In XML there are standard ways of doing this, namely using the  
> xml:lang attribute on an element to specify the language of the  
> content in an element."
>
> -----
>
> I have been thinking about this for a while, and I was picturing a  
> refactoring of the resource handling code so that it can read xml  
> files in addition to *.properties files. The file format would be  
> invisible from a programmer's perspective. In other words, the  
> method call UtilProperties.getPropertyValue("SomeResource",  
> "SomeProperty") would still work even if the "SomeResource" resource  
> was in an XML file.
>
> Or we can just have a utility to retrieve resources from an XML file.
>
> Regardless of how the properties are retrieved, we still need to  
> come up with a strategy (or schema) for the xml file format. I'm not  
> an XML guru, so this is one area where I could use some help.
>
> Do we continue to keep each language in a separate file or should we  
> have all properties for all languages in a single file?
>
> Are there any other issues anyone can think of?
>
> Comments welcome.

I'd like to hear other comments too.

For my part I think it would be nice to have all languages in a single  
XML file. One nice thing about XML is that we can do that sort of  
thing. Some of the ideas around this and shortcomings of the  
ResourceBundle properties files are:

1. the problem where you can't get the US English labels if the server  
locale is set to anything other than en_US, because the "default"  
properties file (with no locale suffix) is the en_US one

2. there is no way to configure the default locale without renaming  
properties files (ie what if someone wants it_IT to be the default  
locale instead of en_US so that if no locale is specified that is what  
will show up, as if the properties file with no locale suffix had the  
Italian labels)

3. the properties files have to be ASCII encoded, so we have to escape  
an transform unicode characters; in an XML file we can just use a  
unicode/UTF-8 capable editor and go for it

4. it is easier to scan down a single file to see what has been  
translated, ie no special properties file tool (like the nice one in  
NetBeans) is needed

-David

[David E Jones]

This is interesting and might be a good starting point, but it doesn't  
look like it helps with any of the stuff I mentioned in the email I  
just barely sent.

I'd rather use something that is more i18n oriented, and less name/
value pair (generic property) oriented.

Maybe something like:

<labels>
     <label key="foo.bar">
         <message xml:lang="en_US">American Foo Bar</message>
         <message xml:lang="en_GB">The Original Foo Bar</message>
         <message xml:lang="es">El Foo Bar en Español</message>
     </label>
</labels>

In a separate file we'd have a default local, or perhaps even a  
primary and secondary default if no label is found in the primary  
locale.

-David


On Nov 26, 2007, at 2:11 PM, Adrian Crum wrote:

> I found the answer to the XML file format - java.util.Properties  
> already supports one:
>
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html
>
>
> Adrian Crum wrote:
>
>> David Jones has suggested in the past that we start moving away  
>> from using properties files for UI labels and such, and use XML  
>> files instead. That subject has come up again in https://issues.apache.org/jira/browse/OFBIZ-1425 
>> .
>> I would be interested in helping out with the implementation, but  
>> I'd like to get input from the developer community first.
>> -----
>> Here are some of the suggestions David made:
>> "If we do something like that, here or anywhere, we should use XML  
>> and not properties files. XML is about 1E6 times better than  
>> properties files (name/value pairs) for organizing this sort of  
>> information. It is hierarchical so much easier to organize and you  
>> can use real UTF-8 characters there instead of having to encode  
>> everything and use a special tool or a translator to work on the  
>> files."
>> and
>> "In XML there are standard ways of doing this, namely using the  
>> xml:lang attribute on an element to specify the language of the  
>> content in an element."
>> -----
>> I have been thinking about this for a while, and I was picturing a  
>> refactoring of the resource handling code so that it can read xml  
>> files in addition to *.properties files. The file format would be  
>> invisible from a programmer's perspective. In other words, the  
>> method call UtilProperties.getPropertyValue("SomeResource",  
>> "SomeProperty") would still work even if the "SomeResource"  
>> resource was in an XML file.
>> Or we can just have a utility to retrieve resources from an XML file.
>> Regardless of how the properties are retrieved, we still need to  
>> come up with a strategy (or schema) for the xml file format. I'm  
>> not an XML guru, so this is one area where I could use some help.
>> Do we continue to keep each language in a separate file or should  
>> we have all properties for all languages in a single file?
>> Are there any other issues anyone can think of?
>> Comments welcome.
>> -Adrian
>

[Adrian Crum]

David E Jones wrote:

>
> This is interesting and might be a good starting point, but it doesn't  
> look like it helps with any of the stuff I mentioned in the email I  
> just barely sent.
>
> I'd rather use something that is more i18n oriented, and less name/
> value pair (generic property) oriented.
>
> Maybe something like:
>
> <labels>
>     <label key="foo.bar">
>         <message xml:lang="en_US">American Foo Bar</message>
>         <message xml:lang="en_GB">The Original Foo Bar</message>
>         <message xml:lang="es">El Foo Bar en Español</message>
>     </label>
> </labels>
>
> In a separate file we'd have a default local, or perhaps even a  primary
> and secondary default if no label is found in the primary  locale.
>
> -David

That's a great suggestion. Keep in mind that existing properties files also contain configuration
settings and system messages. With that in mind, how about something like:

<resource>
     <property key="foo.bar">
         <value xml:lang="en_US">American Foo Bar</value>
         <value xml:lang="en_GB">The Original Foo Bar</value>
         <value xml:lang="es">El Foo Bar en Español</value>
     </property>
     <property key="io-error-message" value="IO error while running the Foo service"/>
     <property key="foo.enabled" value="true"/>
</resource>

-Adrian

[David E Jones]

On Nov 26, 2007, at 3:07 PM, Adrian Crum wrote:

> David E Jones wrote:
>> This is interesting and might be a good starting point, but it  
>> doesn't  look like it helps with any of the stuff I mentioned in  
>> the email I  just barely sent.
>> I'd rather use something that is more i18n oriented, and less name/  
>> value pair (generic property) oriented.
>> Maybe something like:
>> <labels>
>>    <label key="foo.bar">
>>        <message xml:lang="en_US">American Foo Bar</message>
>>        <message xml:lang="en_GB">The Original Foo Bar</message>
>>        <message xml:lang="es">El Foo Bar en Español</message>
>>    </label>
>> </labels>
>> In a separate file we'd have a default local, or perhaps even a  
>> primary and secondary default if no label is found in the primary  
>> locale.
>> -David
>
> That's a great suggestion. Keep in mind that existing properties  
> files also contain configuration settings and system messages. With  
> that in mind, how about something like:
>
> <resource>
>    <property key="foo.bar">
>        <value xml:lang="en_US">American Foo Bar</value>
>        <value xml:lang="en_GB">The Original Foo Bar</value>
>        <value xml:lang="es">El Foo Bar en Español</value>
>    </property>
>    <property key="io-error-message" value="IO error while running  
> the Foo service"/>
>    <property key="foo.enabled" value="true"/>
> </resource>

I haven't thought this through completely yet, but my thoughts on this  
a long time ago were to just leave the configuration settings in  
properties files, and have these be ONLY for i18n.

For configuration settings I don't think we would gain anything, and  
the locale part of the i18n messages doesn't help and can cause  
problems for them.

Actually, the latest direction for many of these settings is that we  
need to refactor them and get them in the database, well the business  
level ones anyway (cache.properties, etc would NEVER go in the  
database).

-David

[Adrian Crum]

Well, that would make my job a lot easier! In other words, the only methods that need modification
are the ones that take a locale. Non-locale methods would default to *.properties files. Correct?

David E Jones wrote:

>
> On Nov 26, 2007, at 3:07 PM, Adrian Crum wrote:
>
>> David E Jones wrote:
>>
>>> This is interesting and might be a good starting point, but it  
>>> doesn't  look like it helps with any of the stuff I mentioned in  the
>>> email I  just barely sent.
>>> I'd rather use something that is more i18n oriented, and less name/  
>>> value pair (generic property) oriented.
>>> Maybe something like:
>>> <labels>
>>>    <label key="foo.bar">
>>>        <message xml:lang="en_US">American Foo Bar</message>
>>>        <message xml:lang="en_GB">The Original Foo Bar</message>
>>>        <message xml:lang="es">El Foo Bar en Español</message>
>>>    </label>
>>> </labels>
>>> In a separate file we'd have a default local, or perhaps even a  
>>> primary and secondary default if no label is found in the primary  
>>> locale.
>>> -David
>>
>>
>> That's a great suggestion. Keep in mind that existing properties  
>> files also contain configuration settings and system messages. With  
>> that in mind, how about something like:
>>
>> <resource>
>>    <property key="foo.bar">
>>        <value xml:lang="en_US">American Foo Bar</value>
>>        <value xml:lang="en_GB">The Original Foo Bar</value>
>>        <value xml:lang="es">El Foo Bar en Español</value>
>>    </property>
>>    <property key="io-error-message" value="IO error while running  the
>> Foo service"/>
>>    <property key="foo.enabled" value="true"/>
>> </resource>
>
>
> I haven't thought this through completely yet, but my thoughts on this  
> a long time ago were to just leave the configuration settings in  
> properties files, and have these be ONLY for i18n.
>
> For configuration settings I don't think we would gain anything, and  
> the locale part of the i18n messages doesn't help and can cause  
> problems for them.
>
> Actually, the latest direction for many of these settings is that we  
> need to refactor them and get them in the database, well the business  
> level ones anyway (cache.properties, etc would NEVER go in the  database).
>
> -David
>

[David E Jones]

On Nov 26, 2007, at 3:23 PM, Adrian Crum wrote:

> Well, that would make my job a lot easier! In other words, the only  
> methods that need modification are the ones that take a locale. Non-
> locale methods would default to *.properties files. Correct?

Correct. I think they are probably better where they are. :)

-David

[Jacques Le Roux]

De : "David E Jones" <[hidden email]>
On Nov 26, 2007, at 3:07 PM, Adrian Crum wrote:

> David E Jones wrote:
>> This is interesting and might be a good starting point, but it
>> doesn't  look like it helps with any of the stuff I mentioned in
>> the email I  just barely sent.
>> I'd rather use something that is more i18n oriented, and less name/
>> value pair (generic property) oriented.
>> Maybe something like:
>> <labels>
>>    <label key="foo.bar">
>>        <message xml:lang="en_US">American Foo Bar</message>
>>        <message xml:lang="en_GB">The Original Foo Bar</message>
>>        <message xml:lang="es">El Foo Bar en Español</message>
>>    </label>
>> </labels>
>> In a separate file we'd have a default local, or perhaps even a
>> primary and secondary default if no label is found in the primary
>> locale.
>> -David
>
> That's a great suggestion. Keep in mind that existing properties
> files also contain configuration settings and system messages. With
> that in mind, how about something like:
>
> <resource>
>    <property key="foo.bar">
>        <value xml:lang="en_US">American Foo Bar</value>
>        <value xml:lang="en_GB">The Original Foo Bar</value>
>        <value xml:lang="es">El Foo Bar en Español</value>
>    </property>
>    <property key="io-error-message" value="IO error while running
> the Foo service"/>
>    <property key="foo.enabled" value="true"/>
> </resource>

I haven't thought this through completely yet, but my thoughts on this
a long time ago were to just leave the configuration settings in
properties files, and have these be ONLY for i18n.
For configuration settings I don't think we would gain anything, and
the locale part of the i18n messages doesn't help and can cause
problems for them.

Yes I agree, less docs to update also...

Actually, the latest direction for many of these settings is that we
need to refactor them and get them in the database, well the business
level ones anyway (cache.properties, etc would NEVER go in the
database).

Having them in properties files is very handy. What would be gains having them in DB, apart that they will become dynamics (which I
agree is not negligible) ?

Jacques

-David

[Adrian Crum]

David E Jones wrote:
> 2. there is no way to configure the default locale without renaming  
> properties files (ie what if someone wants it_IT to be the default  
> locale instead of en_US so that if no locale is specified that is what  
> will show up, as if the properties file with no locale suffix had the  
> Italian labels)

Have you seen an example of this? The UtilProperties.getMessage(...) methods throw an exception if
you pass a null Locale object.

-Adrian

[Adrian Crum]

Easier to configure via web UI.

Jacques Le Roux wrote:
> Having them in properties files is very handy. What would be gains having them in DB, apart that they will become dynamics (which I
> agree is not negligible) ?
>
> Jacques

[Jacques Le Roux]

Thanks Adrian,

I vote for !

Jacques

> Easier to configure via web UI.
>
> Jacques Le Roux wrote:
> > Having them in properties files is very handy. What would be gains having them in DB, apart that they will become dynamics
(which I
> > agree is not negligible) ?
> >
> > Jacques
>
>

[David E Jones]

This has been discussed a few times in the past but was mostly for  
convenience until the discussion came up about creating industry  
specific versions of OFBiz, or at least configurations, through  
database data files.

So these would NOT be technical level configurations, only business  
level ones, like the payment.properties settings as an example, and  
cache.properties as a counter-example (ie we would NOT do this for  
cache.properties).

-David


On Nov 26, 2007, at 3:47 PM, Adrian Crum wrote:

> Easier to configure via web UI.
>
> Jacques Le Roux wrote:
>> Having them in properties files is very handy. What would be gains  
>> having them in DB, apart that they will become dynamics (which I
>> agree is not negligible) ?
>> Jacques
>
>

[David E Jones]

On Nov 26, 2007, at 3:44 PM, Adrian Crum wrote:

> David E Jones wrote:
>> 2. there is no way to configure the default locale without  
>> renaming  properties files (ie what if someone wants it_IT to be  
>> the default  locale instead of en_US so that if no locale is  
>> specified that is what  will show up, as if the properties file  
>> with no locale suffix had the  Italian labels)
>
> Have you seen an example of this? The UtilProperties.getMessage(...)  
> methods throw an exception if you pass a null Locale object.

I can see how the sentence would be confusing, especially not in the  
context of what was in the parenthesis.

The is not the default locale for the system, but the default locale  
to use when there is no properties file for the locale specified.

-David

[Adrian Crum]

David E Jones wrote:

>
> On Nov 26, 2007, at 3:44 PM, Adrian Crum wrote:
>
>> David E Jones wrote:
>>
>>> 2. there is no way to configure the default locale without  renaming  
>>> properties files (ie what if someone wants it_IT to be  the default  
>>> locale instead of en_US so that if no locale is  specified that is
>>> what  will show up, as if the properties file  with no locale suffix
>>> had the  Italian labels)
>>
>>
>> Have you seen an example of this? The UtilProperties.getMessage(...)  
>> methods throw an exception if you pass a null Locale object.
>
>
> I can see how the sentence would be confusing, especially not in the  
> context of what was in the parenthesis.
>
> The is not the default locale for the system, but the default locale  to
> use when there is no properties file for the locale specified.
>
> -David

Understood. I would like to submit a separate patch to provide a configurable default locale -
similar to the work I did to configure a default time zone. The properties code would then fall back
to that default locale if no properties file with the specified locale is found.

-Adrian

[Shi Yusen]

在 2007-11-26一的 16:24 -0700，David E Jones写道：
> This has been discussed a few times in the past but was mostly for  
> convenience until the discussion came up about creating industry  
> specific versions of OFBiz, or at least configurations, through  
> database data files.
>
> So these would NOT be technical level configurations, only business  
> level ones, like the payment.properties settings as an example, and  
> cache.properties as a counter-example (ie we would NOT do this for  
> cache.properties).
I think the XML properties is a great idea.

As I remembered, there are some jars (ofbiz-base.jar and
ofbiz-entity.jar) and properties files needed for OpenCms-OFBiz module.
Next week, I'll try to build a new ecommerce rmi client for 4.0 branch
and report what properties files are concerned. I hope the client can be
deployed without any server side properties files.

Shi Yusen/Beijing Langhua Ltd.

[Vinicius Miana]

Hi all,

I don't think having all the translations in one single file is a good idea:

1) If you do not want to have all translations on your system it is
easier to erase them
2) The person that speaks French is not necessarily the same that
speaks Chinese. With one
single file there will be more people working (committing/merging) the
same file.

Regarding the use of XML instead of properties, I think this is a good
thing and it is worth
taking a look at the apache commons configuration, which uses the Xml
properties API available in
Java 1.5 as well as database configurations and others:
http://commons.apache.org/configuration/

Cheers,

Vinny




On Nov 26, 2007 7:07 PM, Adrian Crum <[hidden email]> wrote:

> David E Jones wrote:
> >
> > This is interesting and might be a good starting point, but it doesn't
> > look like it helps with any of the stuff I mentioned in the email I
> > just barely sent.
> >
> > I'd rather use something that is more i18n oriented, and less name/
> > value pair (generic property) oriented.
> >
> > Maybe something like:
> >
> > <labels>
> >     <label key="foo.bar">
> >         <message xml:lang="en_US">American Foo Bar</message>
> >         <message xml:lang="en_GB">The Original Foo Bar</message>
> >         <message xml:lang="es">El Foo Bar en Español</message>
> >     </label>
> > </labels>
> >
> > In a separate file we'd have a default local, or perhaps even a  primary
> > and secondary default if no label is found in the primary  locale.
> >
> > -David
>
> That's a great suggestion. Keep in mind that existing properties files also contain configuration
> settings and system messages. With that in mind, how about something like:
>
> <resource>
>      <property key="foo.bar">
>          <value xml:lang="en_US">American Foo Bar</value>
>          <value xml:lang="en_GB">The Original Foo Bar</value>
>          <value xml:lang="es">El Foo Bar en Español</value>
>      </property>
>      <property key="io-error-message" value="IO error while running the Foo service"/>
>      <property key="foo.enabled" value="true"/>
> </resource>
>
> -Adrian
>
>
>

[David E Jones]

On Nov 26, 2007, at 8:13 PM, Vinicius Miana wrote:

> Hi all,
>
> I don't think having all the translations in one single file is a  
> good idea:
>
> 1) If you do not want to have all translations on your system it is
> easier to erase them

If you're trying to slim down OFBiz this is the least of your  
problems.... These don't get very big anyway compared to other stuff  
in OFBiz.

This certainly makes it harder, I'm not arguing against that, but I  
don't think this is as high on the list as other priorities.

> 2) The person that speaks French is not necessarily the same that
> speaks Chinese. With one
> single file there will be more people working (committing/merging) the
> same file.

Merging is generally only a problem if two changes happen on the same  
line.

-David

[jonwimp]

Seconding this.

Having translations side by side is great. One XML element for one label is great, with that
single element containing all the possible translations. Conversely, 10 XML elements for one label
in 10 languages is difficult to maintain.

Same concept applies to having a single file for a single set of labels.

About merging problems for the single file, that's what version control is for. To facilitate
multiple collaborative commits to a single set of codes (even a single file).

Jonathon

David E Jones wrote:

>
> On Nov 26, 2007, at 8:13 PM, Vinicius Miana wrote:
>
>> Hi all,
>>
>> I don't think having all the translations in one single file is a good
>> idea:
>>
>> 1) If you do not want to have all translations on your system it is
>> easier to erase them
>
> If you're trying to slim down OFBiz this is the least of your
> problems.... These don't get very big anyway compared to other stuff in
> OFBiz.
>
> This certainly makes it harder, I'm not arguing against that, but I
> don't think this is as high on the list as other priorities.
>
>> 2) The person that speaks French is not necessarily the same that
>> speaks Chinese. With one
>> single file there will be more people working (committing/merging) the
>> same file.
>
> Merging is generally only a problem if two changes happen on the same line.
>
> -David
>

[Vinicius Miana]

I think Jonathon expressed well what I meant. It would be really nice
to have translations side by side,
however it could be a maintenance nightmare to have more than 5
languages. Even though version control
can deal with merging not having to merge is always helpful. Scrolling
down through the translations once
we have more than a few will be more time consuming than scrolling one
line per sentence to translate.

Once think that would be nice is some tool that would tell one what
labels are missing in the resource file.
It could really help ensuring that a translation is complete and up to date.

Did any of you guys take a look at the Commons Configuration?
I think if you are changing the handling of properties it is probably
a good idea of plugging that in.

Vinny










On Nov 27, 2007 3:34 AM, Jonathon -- Improov <[hidden email]> wrote:

> Seconding this.
>
> Having translations side by side is great. One XML element for one label is great, with that
> single element containing all the possible translations. Conversely, 10 XML elements for one label
> in 10 languages is difficult to maintain.
>
> Same concept applies to having a single file for a single set of labels.
>
> About merging problems for the single file, that's what version control is for. To facilitate
> multiple collaborative commits to a single set of codes (even a single file).
>
> Jonathon
>
>
> David E Jones wrote:
> >
> > On Nov 26, 2007, at 8:13 PM, Vinicius Miana wrote:
> >
> >> Hi all,
> >>
> >> I don't think having all the translations in one single file is a good
> >> idea:
> >>
> >> 1) If you do not want to have all translations on your system it is
> >> easier to erase them
> >
> > If you're trying to slim down OFBiz this is the least of your
> > problems.... These don't get very big anyway compared to other stuff in
> > OFBiz.
> >
> > This certainly makes it harder, I'm not arguing against that, but I
> > don't think this is as high on the list as other priorities.
> >
> >> 2) The person that speaks French is not necessarily the same that
> >> speaks Chinese. With one
> >> single file there will be more people working (committing/merging) the
> >> same file.
> >
> > Merging is generally only a problem if two changes happen on the same line.
> >
> > -David
> >
>
>