http://ofbiz.116.s1.nabble.com/XML-properties-files-brainstorm-tp185922p185928.html
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?
>
> 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
>