Re: XML properties files - brainstorm

Posted by David E Jones on
URL: http://ofbiz.116.s1.nabble.com/XML-properties-files-brainstorm-tp185922p185927.html


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