i18n maintainability

[Oleksandr Maksymchuk]

I don't quite understand how to maintain i18n resources, eg
messages_XX.properties files.
Each time I change message in gxp and generate sources, keys in
messages_en.properties are also re-generated.
So I need to find out what new keys were generated and update all my
messages_XX.properties files.
Is there simpler way to do such things?

If one wants to migrate from JSP <fmt:message> to <gxp:msg> why don't
to allow to use already existing resource bundles with specific keys?
E.g. isn't it's useful to support explicit message keys also:
<gxp:msg key="foo.bar">?

Thanks,
Oleksandr Maksymchuk

[Laurence Gonsalves]

On Aug 3, 11:12 pm, "Oleksandr Maksymchuk" <o...@omax.org.ua> wrote:
> I don't quite understand how to maintain i18n resources, eg
> messages_XX.properties files.
> Each time I change message in gxp and generate sources, keys in
> messages_en.properties are also re-generated.
> So I need to find out what new keys were generated and update all my
> messages_XX.properties files.
> Is there simpler way to do such things?

The keys will stay the same as long as the message content does not
change. The keys are hashes of a normalized form of the messages (and
the "meaning" attribute, if present).

The advantage to this approach is that when you change your messages
in the templates, you automatically get new messages that need to be
translated, rather than relying on translations of old versions of the
message which may be wrong or obsolete. The disadvantage is that minor
changes to messages, like correcting spelling mistakes, result in
messages getting brand-new ids. We've found that the latter is *far*
less common than the former, however.

> If one wants to migrate from JSP <fmt:message> to <gxp:msg> why don't
> to allow to use already existing resource bundles with specific keys?
> E.g. isn't it's useful to support explicit message keys also:
> <gxp:msg key="foo.bar">?

It may make sense for us to add a way to explicitly specify a mesage's
ID. My one reservation about this is that we've really found that the
automatic IDs are a huge win. I myself was skeptical about this
approach when it was first proposed but after thinking about it and
then using it (for several years) I now believe that having the IDs
automatically generated like this has a huge net benefit. Not only do
you no longer have to worry about forgetting to retranslate messages
that got edited, but you also eliminate the annoying task of coming up
with meaningful IDs for all of your messages. The downside of
occasionally having to retranslate a message that had a minor English-
only correction is not only rare, but also harmless if your
translation system has a "translation memory".

That said, I don't think we should necessarily exclude the option to
have explicit IDs. I mostly just worry that some people may assume
that they need explicit IDs (since so many other systems require them)
and miss out on the benefits of explicit IDs. :-)

For people migrating from JSP and the like, I wonder if it would be
better to just have a tool to remap existing properties files to the
message IDs that GXP uses.

By the way, our i18n support in the open source release of GXP is a
bit rough at the moment. This is part of the reason we're calling this
"version 0.2". At Google we use the XMB output for translations, and
have a separate set of tools for managing them. We haven't completely
worked out what the full translation pipeline should look like for GXP
users outside of Google. Any suggestions in this area would be
appreciated.

[Oleksandr Maksymchuk]

I agree that it's very hard to come up with meaningful ID, buts it's
okay only if one person is responsible for naming stuff and there are
some guidelines for that although it creates some complexity for
new-comers.

I think for now it would be simple just to introduce support of
explicit key attribute for those how are sticky to them.
If you at google use auto-generated keys, the thing I don't understand
and it se in GXP messages is how translator which is supposed to be
some external person can correct English messages. They are not
supposed to touch a bit of code, just to edit/correct messages.
Sounds like there is no way to do this without pair work with
developer who then renames all generated keys based on what other
party corrected?

In my project I use simple messages_XX.properties and messages_XX.js
files generated from single google spreadsheet document with all
translations. The base messages.propertis and messages.js are added to
the repository and state required set of keys and messages in English.
So developers can add new messages in english with meaningful keys,
translator(s) can correct messages and those will override developers
input and could request additional keys from developer.
I find this quite productive and there is no big coupling between dev
and translators.

[Laurence Gonsalves]

On Aug 4, 1:14 am, "Oleksandr Maksymchuk" <o...@omax.org.ua> wrote:
> I think for now it would be simple just to introduce
> support of explicit key attribute for those how are sticky
> to them.

There might be some trickiness with how this interacts with
placeholders. That said, if it turns out that there's
significant demand for this feature then I agree that we
should add it.

> If you at google use auto-generated keys, the thing I
> don't understand and it se in GXP messages is how
> translator which is supposed to be some external person
> can correct English messages. They are not supposed to
> touch a bit of code, just to edit/correct messages.
> Sounds like there is no way to do this without pair work
> with developer who then renames all generated keys based
> on what other party corrected?

We never expect our translators to edit anything but the
language they're translating to. However, this should
still be doable with auto-generated message IDs. The
properties files you use at runtime don't have to be the
ones generated by the GXP compiler. More on this below...

> In my project I use simple messages_XX.properties and
> messages_XX.js files generated from single google
> spreadsheet document with all translations. The base
> messages.propertis and messages.js are added to the
> repository and state required set of keys and messages in
> English. So developers can add new messages in english
> with meaningful keys, translator(s) can correct messages
> and those will override developers input and could request
> additional keys from developer. I find this quite
> productive and there is no big coupling between dev and
> translators.

Using a Google Spreadsheet for managing translations is a
clever idea!

As mentioned above, I think it should be possible to use
auto-generated message IDs and still let translators edit
the English messages as well. One way to do this would be to
use the compiler generated properties files only for adding
new messages to the spreadsheet. Let's say it's one message
per row, with one column for the message ID and another
column for each language's version of the message. You'd
then add a new row to the spreadsheet whenever a message ID
appears in the compiler's output that doesn't already appear
in the spreadsheet. It should be possible to automate this
step using the Google Spreadsheets Data API. The translators
could then edit any column (including the English column)
except for the message ID column (which would be an opaque
number). You'd then generate a .properties file from each
language column, including the English column. This could
also be automated with the Data API.

The one downside to this approach is that the corrections
made in the spreadsheet would not be reflected in the GXP
source code. This could be a litle confusing in debugging,
though this may still be better than not having the English
text appear in the templates at all, especially if edits to
the English text in the spreadsheet only happen
occasionally.

My guess is that you'd want to limit English edits in the
spreadsheet to minor edits, like spelling correction or
simple rewordings, and do major edits, like changing the
meaning of a chunk of text, in the GXPs. That way major
changes would result in new messages to be translated,
rather that risking version skew between the English and
translated text. This is a policy issue, though, so it's up
to the maintainers of a project how they want to deal with
this.