I suggest we switch Zanata's GWT translations[1] to use "Localized Properties Files"[2] rather than @DefaultMessage annotations[3], with a view to making it the recommended GWT solution for Zanata-based projects.

According to the GWT docs, this approach uses "traditional Java .properties files" and going by the properties files in the Guvnor project, it does support '\n' sequences[4].  It also removes the need to generate .properties files by running a GWT compile, which should make life easier and save some time.  It even seems to use the standard directory layout for properties files, which might remove the need for our client-side command hooks.

The only drawback seems to be the duplication of properties keys between the .java interface and the .properties file, but on the whole it seems like a much simpler and safer approach, at least if it really uses "traditional Java .properties files".

Put simply, we would move the English text out of the @DefaultMessage annotations in our Messages interfaces, and into .properties files (which we can generate from the @DefaultMessage annotations).  The .properties files would then be checked in like any other source code.  We would also change the build process to pick up the translations from the .properties files.  When it comes to pushing content into Zanata for translation, we will be able to pick it up just the same as we do for our JSF pages, instead of having to run a partial build to generate the files.



[1] http://www.gwtproject.org/doc/latest/DevGuideI18n.html#DevGuideStaticStringInternationalization

[2] http://www.gwtproject.org/doc/latest/DevGuideI18n.html#DevGuidePropertiesFiles

[3] http://www.gwtproject.org/doc/latest/DevGuideI18n.html#DevGuideAnnotations

[4] Newlines in @DefaultMessage cause trouble, because GWT generates an incompatible .properties file with <backslash><newline> instead of using using '\n'.