[udig-devel] German translation update and a request to all "String builders"

[Jesse Eichar]

Sorry Matthias.  I will try to do better.  I am guilty of this far  
too often.

Jesse

On May 5, 2007, at 2:22 PM, Matthias Basler wrote:

> Hi uDiggers,
>
> once again I have committed the German adaptations to the latest  
> changes in the properties files.
>
> One thing I noted and about which I was very disappointed is that  
> obviously many developers of uDig still think it a good idea to  
> build dynamic Strings in the following way:
>
> String myMessage = msgPart1 + someFile + msgPart2 + someOtherContent;
>
> To give a "nice" example from "WorldImageServiceExtension":
>   return
> Messages.WorldImageServiceExtension_needsFile+"\n\t-"+worldFile 
> +"\n"+Messages.WorldImageServiceExtension_or+"\n\t-"+otherWorldFile;
>
> For all of you who havn't yet realized: This is a very bad way to  
> build dynamic Strings for four reasons:
>
> 1. Not every language splits sentences in the same way as English.  
> For example if you have two arguments a foreign language might  
> integrate them in different order. Can you tell how a Chinese  
> translator would build up the sentence???
>
> 2. Having two or three sentence parts (or single words) as texts in  
> the .properties files makes it sometimes hard to guess (without  
> looking at the source code) which texts will be combined how later.
>
> 3. Some of the cases even expect whitespaces in the properies files  
> (otherwise they end up with something like
>   "The fileimage.pngcould not be loaded because  
> ofNullPointerException.")
> My ressource bundle editor ignores (and deletes) trailing  
> whitespaces, and I tend to say that it does so correctly, because  
> leading and trailing whitespaces in properties files are really a  
> bad habit.
>
> 4. Sentences that try to avoid correct dynamic structures often  
> take the form "I have this or that problem with following file: " +  
> myfile
> So they end with a colon and then give the argument. While this is  
> usually not a problem in English language, this structure leads to  
> unaesthetic and forced sentences in other languages.
>
> I hope these arguments are enough to reconsider your choice!
>
> So, PLEASE, whenever arguments are needed in Strings, try to use the
> MessageFormat.format(string, arguments) function or something similar.
> Example:
> MessageFormat.format(
>     "This is a dynamic String with {0} and {1}.",
>     new Object[]{"Argument 1", "Argument 2"})
> There are already some examples of this in uDig source code, so  
> probably people DO know but simply are too lazy or too much in a  
> hurry to care.
>
> Maybe each module maintainer can check his/her module for occurrences?
> This is a problem very common in the catalog plugins (e.g. for  
> error messages), but I found it in a few other plugins as well.
>
> PS. I havn't created a JIRA task yet, simply because having this as  
> ONE task would create one of those "never finished" tasks and  
> because I am too lazy to create an issue for each and every plugin.
>
> PPS. Tip: If you really need whitespaces in your code, use ' ' and  
> '\n' instead of  " "  resp. "\n" and you can save yourself the "// 
> $NON-NLS-1$".
> -- 
> Matthias Basler
> matthiasbasler at earthflight.org
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel