http://ofbiz.116.s1.nabble.com/Externalizing-strings-need-some-feedback-please-PEASE-READ-tp173024p173026.html
Is this aspect there is still some work to do. For instance I will soon drop all Common labels that are in *_fr.properties files and
not in other *.properties files (default properties file being the reference). It seems indeed that some cleaning have been done and
I don't want to stop your effort but from my point of view even if it's "not the end of the world" your work could have a great
Normalising labels names sounds good to me. For the dot separator I agree with what was already said.
And last but not least I agree with David's 1st paragraph, not an easy task for sure...
PS : sorry I guess this message is not clear. Let me ask a question : why did you choose to make a such task in OFBiz ?
>
> Gerrie,
>
> This is an interesting effort, but I think it would cause serious
> problems if we externalized ALL strings. I'm all for externalizing
> error messages to support localization efforts. But for many things
> externalizing strings would make the code more complicated, error
> prone, and difficult to maintain, and that is a big problem for a
> project like OFBiz. Developer efficiency and avoiding complexity is
> very important in order to be able to handle a large volume of
> business logic with as little code as possible, and among a small
> group of people.
>
> On the property name issue: I'd prefer names that do not use dots for
> word separators because in some code, like in FreeMarker ${} and in
> the various OFBiz XML file attributes that support the Flexible
> String Expander with the ${} syntax, it causes problems because dots
> are interpreted as meaning the symbol to the left of the dot
> represents a Map name and the one to the right of the dot represents
> a Map entry key. Actually, we really should change all of the
> existing ones that have dots to use capital letters to separate the
> words instead.
>
> I hope that helps... though I recognize that especially the first
> comment doesn't really make it easier...
>
> -David
>
>
> On Oct 6, 2006, at 11:40 AM, Gerrie Myburg [ MTN - Innovation
> Centre ] wrote:
>
> > PLEASE READ! Not the end of the world, but if I start booking in the
> > code a lot of people can be very pissed off if they don't agree with
> > what I need to do.
> >
> > Externalizing strings.
> > I can now externalize all the strings in the ofbiz code base. I
> > used the
> > antlr parser generator and a JAVA 1.5 grammar to write a program to do
> > it.
> >
> > The problem I now have is that there is more than one resource file
> > per
> > module and that the format for the key strings differs from one module
> > property file to the other module property file.
> >
> > The first question is the number of property files per module. Can we
> > not have one property file per module? I understand that the different
> > files create a namespace effect, but this same effect can be gotten by
> > encoding the namespace in the property key. Eg
> >
> > error.ui.get.lost=You made a mistake. Go to the start and try again.
> >
> > If we do this then all the property strings can be in one file. I
> > would
> > prefer one property file per module with the namespace encoded as part
> > of the key.
> >
> > The second issue is the key string format. I need to now what is the
> > preferred key string format please? There are 2 formats in general
> >
> > Example
> >
> > 1. Name1Name2Name3 - like a java id with the first letter in caps
> > 2. name1.name2.name3 - '.' in place of the spaces
> >
> > Some of the keys also contains contextual information eg
> >
> > error.module.name1.name2
> >
> > I can try to place contextual information in the generated keys for a
> > message when I run the program that extract the strings, but don't
> > hold
> > your breath as this is VERY hard to do in principle.
> >
> > If I can get some consensus on the format of the key strings then I
> > will
> > go and change all the key string and property files to the same
> > format.
> > If nobody responds to this mail then I will change all the key strings
> > as in format 2 above. It is more readable for me. THIS CHANGE AFFECTS
> > ALL THE FILES IN ofbiz!
> >
> > There are more problems with the message string constructions that I
> > never foresaw and cannot find a simple way to resolve. This relates to
> > constructs like
> >
> > String message = "this " + ( isThere == null ? " is " :
> > isThere.toString) + ".";
> >
> > I need to go and rewrite the message by hand in such a way that it can
> > be translated to other languages. The above example does not happen
> > often. I cannot guarantee that there are other messages that are
> > constructed in a similar manner. We will just have to go through the
> > code looking for other strange examples.
> >
> > One disadvantage of programmatically restructuring code is that it is
> > hard to deal with exceptions. One example of exceptions is the
> > construction of strings contacting
> >
> > 1. SQL
> > 2. html
> >
> > String. If no one complains about this then I will extract these
> > strings as well.
> >
> >
> > NOTE: This e-mail message is subject to the MTN Group disclaimer
> > see
http://www.mtn.co.za/default.aspx?pid=34411>