A little update on the status of i18n
Daniel Leidert wrote:
After testing, internationalisation seems to work correctly. But there
are still some things to do:
(1) Nicholas suggested to use context wrappers for special strings,
which could be problematic, e.g. "All" and "None". I suggest to do the
following:
In such a case, we should use
"[labelNoneAtoms]None"
"[labelNoneBonds]None"
....
as strings. GT.java must be adjusted to remove '[label[a-zA-Z]*]' from
strings and only return the part, which follows these strings.
Still to be done. I will do it.
(2) GT.java throws an MissingResourceException for LANG=C (en_US). Maybe
it would be a good idea, to add a test, if LANG=C and then directly set
translationResources = null, if LANG=C, because the C locale is covered
by the original strings.
Should be fixed.
I also removed a lot of outputs to System.out.
(3) build-i18n.xml should be fixed to run gettext-suite applications
also under Windows, not only under Linux.
It works.
(4) .properties files should no longer contain translatable strings, but
variables, which can differ for several languages (e.g. About.aboutURL,
WhatsNew.changeLogURL ...).
Done.
(5) Strings like "100%" or "0.5 Å" should not be translatable, because
they are always the same for every language.
Done for the popup menu, I think a few of them still exist for the rest
of the application.
One other thing that should be done also is using strings with variable
parts instead of having to translate eache possiblity, like :
- <x>% vanderWaals
- <x> pixels
- scale <x>
I will do it.
(6) Further I would suggest to control the adequacy of strings, e.g.
"AtomSetChooser" should maybe something, a normal user understands. Or
in View-menu, the "All" and "None" should maybe be "Show all" and "Show
none" (+ context markers).
Comments, suggestions, concerns, solutions?
Currently, the i18n mechanism for the application/applet is almost stable.
*One thing* that still needs to be decided (Miguel ?) : in which
JmolApplet<x>.jar do we put the translation classes for each language.
Several possibilies :
- in an existing JmolApplet<x>.jar
- in a new JmolApplet<x>.jar
- in several JmolApplet_<lang>.jar so that only one small jar would have
to be loaded.
The third solution would require to modify Jmol.js to add the correct
JmolApplet_<lang>.jar to the archive.
Nicolas
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
