[udig-devel] Re: uDig Internationalization

[Matthias Basler]

> We have been discussing some of the issues related to the (non-standard)
> way that uDig does internationalization, and since Paul wants to
> implement some tools to assist this process, now is the best time to
> address these issues.

Sounds good. Let's see what is suggested ...

> I propose we:
> 
> 1) Eliminate Policy class 
>  - replace it with Java standard way (Messages in each package - any
> downsides to this?)
>  - Messages class and messages.properties would live in the package that
> they correspond to. 
> 
> 2) Eliminate nl1 Fragments
>  - Original intention was so we could separate main uDig download from
> translation downloads
>  - Currently we include the fragments in each download anyway
>  - The increase in download size is currently trivial. This will only
> grow substantially if help guides with screen-shots are translated. If
> this becomes a problem, we could only include the English help guide
> with the download, and host the translated ones on the website, or make
> them available via the update manager.
>  - Translations would live beside their original language strings

OK, since this is my business I have strong opinions on this:

1. My efforts needed for translations increase linearily with
    - the number of plugins/nl1 fragments
    - the number of properties files.
    - much less with the size of them, since usually I spend more time
      finding the changes than fixing them

2. One single messages.properties file per plugin is perfect for me, for the above reason. The more files, the more I have to check for changes.

3. Also having several Messages classes means code duplication (multiplication actually), which I hate. Having just one makes it easier to ensure that all these classes provide the same convenience methods, e.g. for fetching Strings with "{0}" arguments. (In short: easier maintnance.)

In a huge codebase such as the Java SDK there is a need to structure the location of Strings, for several reasons. In a codebase like uDig that's already splitted into plugins and maintained by a manageable group of people, there's no need to follow the "one properties file per package" rule, imho.

4. Having the English and translated files live side by side would make the work with ResourceBundle Editor MUCH easier, since the editor assumes the files are together in order to find differences (e.g. missing properties).
Also, as stated above, less plugins/fragments means less maintnance work.

I am unsure about possible disadvantages, however. For one thing, the notion of  NL1 fragments in Eclipse was not pure fun: NL1 fragments allow the translations to be done separately from the code, which theoretically allows to give translators just SVN access to NL1 fragments. Also 3rd party application providers might skip the existing NL1 fragments when packaging their own apps and do not need them. Last but not least I like the idea of a NL1 feature that can be turned on and off.
Still, all these points are not anything that, imho, requires NL1 fragments to exist in any case for all plugins.

NL1 fragments are mandatory, however, if there is languaged-dependent code, images, icons, etc. This applies to the help plugin, the product plugin and possibly a few others. Anyone cares about this inconsistency?

5. I would also help a lot if "dead" (unmaintained) languages are removed from the system, since they make the ResourceBundle Editor show signs of "missing translations" all over the place, even if my German translation is fine. (I can, of course, remove them each time on my local machine, it's just a bit more work for me, and I must be careful when committing.)

To sum up, if I could decide:
±0 for replacing Policy with Messages. I don't see a difference.
+1 for dropping all those NL1 fragments that don't have code/images/...
-1 for messages.properties in (nearly) every package.
+1 for moving orphaned languages out of trunk until someone cares again.

Hope this helps for your decision.
-- 
Matthias Basler
matthiasbasler at earthflight.org