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.