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.