Posted by
Jacques Le Roux on
URL: http://ofbiz.116.s1.nabble.com/XML-properties-files-brainstorm-tp185922p185933.html
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