Re: i18n: should cf-cli strings be exact duplicates of en-US translations?
Kris Hicks <khicks@...>
The workflow is available here:toggle quoted messageShow quoted text
i18n4go, goi18n, bin/generate-language-resources are the three things that
need to be executed when updating any calls to the i18n.T() function (which
tends to be dot-imported, so it's just T()).
i18n4go digs through the AST to find calls to T(). It assumes you want the
strings that are in your call to T() as your translation key and (English)
value, and modifies the en-us.all.json accordingly. It also has the ability
to detect changes and removals.
goi18n is what fills out the *.translated.json and *.untranslated.json
files with those keys that are present in en-us.all.json but missing in,
for example, fr-fr.all.json. It puts empty values in the .translated files
and the English value in the .untranslated files.
bin/generate-language-resources rebuilds the binary representations of
those JSON files into i18n_resources.go
To use keys instead of the English values in calls to T(), i18n4go would
need to be changed to just do the add/removal of keys, but leave empty
values in the en-us.all.json file for new entries (rather than adding the
English value as well). The English value would be added manually to that
file at that point.
That in itself isn't too complicated, except for the fact that i18n4go
doesn't have much in the way of tests, so making modifications should be
done with care.
The part that's not so great is that once you start switching to keys, you
need to switch everything to a key at once otherwise i18n4go will not be
very useful at all. For example, if you switched one call to T() to be a
key instead of English, i18n4go would want to remove the old key and value,
and add the new key with a value that's the same as the key. You'd have to
restore the English value to the new entry. If you were to add a new call
to T(), you'd also get limited usefulness out of i18n4go as it would modify
the en-us.all.json to add the missing entry (which would have the correct
key, but wrong value), but you'd still need to update the value. The
workflow is already not very good; it would just be worse in this scenario.
Using proper keys also tends to imply an order/hierarchy/convention to the
keys, and that requires a bit of thought to properly model both the
existing strings and new ones.
I haven't been on the CLI team for a number of months now, so some of the
above may have changed.
On Thu, Sep 15, 2016 at 5:18 PM John Feminella <jxf(a)pivotal.io> wrote:
The tooling around updating translations all assumes a particularworkflow, which would need to change: i18n4go pores through the source code