Re: Externalizing strings - need some feedback please - PEASE READ.

Posted by cjhowe on
URL: http://ofbiz.116.s1.nabble.com/Externalizing-strings-need-some-feedback-please-PEASE-READ-tp173024p173028.html

I generally have very little opinion on the
externalizing of strings.  However, because these
variables are primarily used in a freemarker syntax, I
would prefer it remain Name1Name2Name3 format.  I'm
not sure if I would call it a naming convention or a
naming convenience, but the "." in freemarker
distinguishes a node.  I think it is possible that it
creates issues with the creation of the label maps.

Also, the externalized string shouldn't necessarily be
"readable".  Translation is in context of it's usage,
not translating the words that are present.  While it
may make quick work of tranlating strings, those
translations can be quite innacurate, meaningless,
embarrasing, or offensive if not regarded in their
context.

--- "Gerrie Myburg  [ MTN - Innovation Centre ]"
<[hidden email]> 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
>