ok, I don't fully understand why it is better to use a different
"compressed" path than what
is used in the src plugin - but if that is what the translators find best
then ok.
Is the build capable of failing if a resource gets moved/renamed and you
can't find a match ?
/max
G'day all,
I finally bit the bullet and put in a somewhat kludgy workaround for the
fact that properties files are not kept in the same directory under each
plugin, but all over the place (src, src/main, resources, jbosscore,
...). I can always take out the workaround when
https://jira.jboss.org/jira/browse/JBIDE-2972 is resolved.
With the workaround, the pot filenames should be fairly stable, so I've
checked in the converted pot files under i18n/po.
I really, really tried to avoid checking in generated files like pot
files. However, keeping pot files in the source tree seems to be a
universal convention for gettext projects, and corresponding pot and po
files are usually kept in the repository together. This enables
(non-programmer) translators to merge new strings for translation just
by checking out the po directory, without having to run xgettext (or
Ant-Gettext, in this case) against the entire codebase themselves.
Based on feedback from the L10n team, I have also changed the filename
mapping used when converting from .properties to .pot files. The pot
filename now eliminates segments like "src", "src/main",
"resources",
"jbosscore", etc which are very likely to change over time. I have also
flattened the remaining directory hierarchy.
I think this retais enough of the original path to prevent name
collisions, but shortens it enough to be more changeproof and easier for
translators to work with.
With the new mapping, the names of source directories can be refactored
without affecting the .pots and thus invalidating translations. For
instance, changing myplugin/src/**/*.properties to
myplugin/resources/**/*.properties is perfectly safe. But changing the
name of a module, a plugin or a .properties file (or its package) will!
(See the end of this email.)
Thus the property file org/hibernate/console/ConsoleMessages.properties
in the plugin org.hibernate.eclipse (module hibernatetools) is mapped to:
i18n/po/hibernatetools/org.hibernate.eclipse-org.hibernate.console.ConsoleMessages/
org.hibernate.console.ConsoleMessages.pot
The po/pot files are still grouped into modules (for managability), and
we keep track of the plugin id and the resource path (ie the path used
at runtime to load the resource). The resource path is used again for
the filename within the directory, partly to make it easier to find (eg
in Eclipse, press Ctrl-Shift-R, the enter *ConsoleMessages or other
wildcard).
In accordance with the Gettext tools' default conventions, po files will
be kept in the same directory, but named ${locale}.po. So the above
directory will look like this when translated:
i18n/po/hibernatetools/org.hibernate.eclipse-org.hibernate.console.ConsoleMessages/
de_DE.po
es_ES.po
fr_FR.po
org.hibernate.console.ConsoleMessages.pot
pt_BR.po
zh_CN.po
Please be careful:
1. when renaming modules, plugins, .properties files, or packages which
contain .properties files, or
2. when moving plugins to a different module.
Any of these changes will prevent existing translations (when we have
some) from being picked up, unless the affected po directories and files
are manually renamed to suit. By me, probably. But feel free to rename
the affected po directories/files if you feel confident to!
I'm certainly not saying "don't rename things", but please try to go
easy on me! Thanks!
Regards,
Sean.