The problems with internationalization are not so much the technical problems as to how it works but more so the problems are with getting, keeping and coordinating the correct competences to do the job. This comes from the fact that, as would be expected, the different persons working with internationalization often have different native languages which complicates the communication.
To handle this problem for GNU applications there is a community set up around “gettext” with one language team per language working with all “gettext” applications. There are also tools to help the translator do his job delivered with “gettext” that are the same for all the applications. In each of these language teams discussions are held that ensure a consistent use of words over all these applications.
It is for me (Linus Tolke, May 2002) unclear if and how such a community exists for Open Source Java tools and ArgoUML cannot simply benefit from the “gettext” communities since we don't use “gettext” and cannot use the same tools.
To get things done, we organize our own Language Teams for ArgoUML. Each language team is actually just one or several persons that know that language and are eager to work with translating ArgoUML.
The language team has the following responsibilities:
- Constitute the foundation of the ArgoUML community for that language.
- Translate all localized strings and resources.
- This is a constant work with keeping up with the changes that will be made to the ArgoUML code and ArgoUML modules since ArgoUML is under fast development.
- The terminology used shall be correct.
- This requires work in keeping up with the current literature in the domain of ArgoUML.
- Help with the improvements on ArgoUML by pin-pointing where ArgoUML needs to be modified to allow for localization.
- As ArgoUML was originally built without localization there may still be places in the GUI that are not localizable just by modifying the resource bundles. Each such place is a Defect and shall be corrected.
- See that the used libraries also provide their part in that language.
- This is mostly GEF since GEF is central both when it comes to the fact that it has localized strings of its own but also because it handles parts of the localization.
- This means discussing with the teams developing the underlying package as to how best to provide the localization for those parts. Either by providing localization for that team to include in the package or by having ArgoUML overriding that package in that respect.