XML properties files - brainstorm

[Jacques Le Roux]

I used to use RBE http://docs.ofbiz.org/display/OFBIZ/Plugins#Plugins-RBE  http://docs.ofbiz.org/display/OFBIZ/Tips+for+translation
for such tasks. I got some problems recently using it (with last version) but it's still the best tools for this kind of tasks even
if in some case I still use the sandard Eclipse properties editor.

I'm not sure we want to do such a things but having an UI like in RBE is certainly a must when it comes to deal with several
languages...

Jacques

De : "Vinny Miana" <[hidden email]>
> 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.

RBE is great for that

> Once think that would be nice is some tool that would tell one what
> labels are missing in the resource file.

RBE do that (parameter)

> 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.

I hope Adrian will see this message since he seems to want to handle the task.

> 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
> > >
> >
> >
>

[Jacques Le Roux]

De : "Vinny Miana" <[hidden email]>
> 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

I just took a glance and I reckon that it's a good idea !

Thanks

Jacques

[Adrian Crum]

Vinny Miana wrote:
> 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.

I just took a look at it, and it's not suitable for what has been discussed so far. Commons
Configuration is geared toward configuration settings, not i18n translation.

-Adrian

[Walter Vaughan]

David E Jones wrote:

>
> 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.

As has been said many times, the target is not an OOTB solution.
Otherwise someone would build a webapp that would collect information,
configure, and automatically setup and start OFBiz like how SugarCRM,
phpBB, phpMyAdmin, and countless other projects work for installation.

[David E Jones]

On Nov 27, 2007, at 12:56 PM, Walter Vaughan wrote:

> David E Jones wrote:
>
>>
>> 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.
>
> As has been said many times, the target is not an OOTB solution.  
> Otherwise someone would build a webapp that would collect  
> information, configure, and automatically setup and start OFBiz like  
> how SugarCRM, phpBB, phpMyAdmin, and countless other projects work  
> for installation.

I wouldn't say the "target" isn't an OOTB solution, or more accurately  
maybe a set of OOTB solutions. What I've said over and over is that  
the project and current efforts are not really geared toward creating  
an OOTB solution.

-David

[Adrian Crum]

Okay, I have this working now. There is one question I need answered...

The ResourceBundle class looks for the resource using the specific locale first, and if it's not
found it looks for progressively less specific locales. If all of those fail, it repeats the process
with the system's locale. If THAT fails, it looks for a resource that isn't locale-specific.

I have the XmlResourceBundle working the same way except for the last step - I'm not sure what to do
there. My question is: Do we want to have <value> elements with no xml:lang attributes to fall back
on if no matching locale is found? Or do we want to make xml:lang="en" the choice of last resort?

-Adrian

David E Jones wrote:

>
> 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
>

[David E Jones]

On Nov 27, 2007, at 4:30 PM, Adrian Crum wrote:

> Okay, I have this working now. There is one question I need  
> answered...
>
> The ResourceBundle class looks for the resource using the specific  
> locale first, and if it's not found it looks for progressively less  
> specific locales. If all of those fail, it repeats the process with  
> the system's locale. If THAT fails, it looks for a resource that  
> isn't locale-specific.
>
> I have the XmlResourceBundle working the same way except for the  
> last step - I'm not sure what to do there. My question is: Do we  
> want to have <value> elements with no xml:lang attributes to fall  
> back on if no matching locale is found?

I'd say definitely no, because then we're back with the same problem  
where we are now with properties files with no suffix as I described.

> Or do we want to make xml:lang="en" the choice of last resort?

This is the configurable default message to use, ie the locale to use  
if the one requested was not found. We had a little email back-and-
forth where you were asking about this default, and maybe my second  
answer still wasn't clear enough, but this is exactly what I was  
talking about.

So anyway, we need a configuration to set a couple of locales to look  
at if we don't find what the user requested, and if those are  
configured or something then yeah we could default to "en" or  
"en_US" (since that is the main language so far for OFBiz...).

-David

[Adrian Crum]

David E Jones wrote:
> This is the configurable default message to use, ie the locale to use  
> if the one requested was not found. We had a little email back-and-
> forth where you were asking about this default, and maybe my second  
> answer still wasn't clear enough, but this is exactly what I was  
> talking about.

Your answer was clear enough, I was giving others a chance to respond. ;-)

-Adrian

[Adrian Crum]

The XML properties feature has been submitted to Jira -
https://issues.apache.org/jira/browse/OFBIZ-1442.

Many thanks to everyone for their input!

-Adrian

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
>
>
>