goi18n could harvest untranslated strings automatically about go-i18n

[nicksnyder]

I initially implemented similar functionality in goi18n myself until came to the conclusion the developer must do a few things manually anyway:

• The developer needs to provide the translation in the source locale, which is not extractable from the code if you are using generic ids.
• *.untranslated.json can't contain strings without a translation because the translator needs something to translate
• The developer should write a comment to each translation to give the translator more context (I need to add support to the data structure for this). This is not extractable from the code either.

Is it really that cumbersome to add a new string to a project?

{
  "id": "settings_title",
  "translation": "Settings"
}

[rtfb]

The strings in the source locale can be self-identifying, i.e. the string "Settings" can also be an ID for "Settings". I haven't given much thought about how could plurals be identified yet, but at least we can know when Tfunc is called with extra parameters and treat these as plurals.

Handling comments is also easy to solve by convention. The tool can look for adjacent comments that start with some predefined (or configurable) prefix and transplant those:

// L10N: please leave %s in the translation
T("Error %s", err)

$ goi18n -sift src/ -comments="L10N" *.json ->

{
  "id": "Error %s",
  "translation": "Error %s",
  "comment": "please leave %s in the translation"
}

I didn't really understand what do you mean by a second bullet point.

Adding new strings to the project is bearably cumbersome, but it's error prone. If you add a string to the code, but not to translation files, the only way to discover that is to have a bug in production, whereas the problem is mostly (if not completely) solvable by tooling.

[nicksnyder]

It is better if the id is distinct from the source translation

Your source translation might be very long:

T("This awesome new product enables turnkey solutions to your enterprise cloud software development stack and accelerates the synergies at you company to an unprecedented velocity blah blah blah")
T("productDescription") // better

You might need a word translated differently in different contexts (e.g. a homograph):

T("Update") // noun
T("Update") // verb

// Better
T("update.noun")
T("update.verb")

There might be a valid reason to pass a variable to the T function, which would prevent the string from being extracted

productDescription := "This awesome new product enables turnkey solutions to your enterprise cloud software development stack and accelerates the synergies at you company to an unprecedented velocity blah blah blah"
...
T(productDescription)

Other questions you would need to think about:

1. How do comments work in Go?
2. How do comments work in templates?
3. If the same string has two different comments, which one is used? Are they concatenated?
4. How do you specify plural forms without adding unnecessary parameters to the API?

These are only the edge cases that I was able to think of off the top of my head; there might be more.

I would be opposed to any solution that adds unnecessary parameters to the runtime API.

I also don't think it is worth it to invent a new syntax to embed translation metadata in Go comments (comments, pluralizations, etc.) when the developer can just put that data directly in a JSON file. The metadata needs to end up in the JSON file anyway.

I think having a consistent workflow is paramount, so any tooling solution should solve all of the use cases mentioned above without any surprising edge cases. I don't see an eloquent solution, so I would rather error on the side of consistency and simplicity.

[rtfb]

Hmm. Well I approached this along a line of thought that if gettext can do that in C, it should certainly be possible for us to do in Go :-)

I guess I'll pursue this goal as a separate project at least as far as my own needs go and then we can check again on which issues still stand out.

Thanks for your feedback!