Automatic messages extraction?

[bubenkoff]

Thank you for the great project!
One thing really missing is message extraction utility.
Any plans for implementing that?
Thanks again!

[nicksnyder]

This has been discussed before in #7.

I am not a fan of having the source code be the source of truth for original translations for a few reasons.

• For plural forms you need more than one source translation
• You may want to provide a comment to the translators
• You should use unique ids for translations because of homonyms and phrases that need to get translated differently in different contexts

The proper way to do this is to use ids in your source code and then create store your source translations in the same kind of file that your translations are in. As such, "extraction" doesn't make that much sense since if you are doing translations properly, you will need to modify your translation file anyway for each new string.

That said, having a lint tool to to detect missing ids, or unused ids may/could be useful.

[bubenkoff]

by automatic extraction i mean that in source code you'll have ids, not just strings, like:

func (pl *EmailPackageCollection) Description() i18n.Translation {
	return i18n.T("pricing.email_packages.description")
}

then when you run some script like

goi18n extract -outdir locales 

it will add to json

  {
    "id": "pricing.email_packages.description",
    "translation": "TODO: pricing.email_packages.description"
  },

and pluralization is totally possible as well, because the call of i18n.T can be parsed smartly

[nicksnyder]

This is certainly possible to do, but I guess I am not convinced that it is worth the effort since a developer has to go in and write the source translation anyway.

Maybe you can explain more why you think this would be helpful? Is it really that hard to manually add an entry to the json file every time you add a new translation?

[bubenkoff]

The main issue i have is that it's hard to keep translation files in sync with the codebase.
Currently the file is about 1000 lines long, and it's very easy to miss one or two strings, also you might remove some string from the codebase, and forget to remove it, which then leaves rubbish in the file.
If we have the procedure to extract strings, it's then trivial to look up for TODO: strings and if there are any, translate them - very easy
this is standard procedure of i18n flow, automatic message extraction

[nicksnyder]

Since this seems to be a common request, I am open to considering this. I imagine the API would look something like this:

T("thisIsTheId", "Hello world")

The first parameter is the id for the translation and the second parameter is the default source translation.

A more complicated example:

T("numberOfEmailsInThePastTime", "{{.Person}} has {{.Count}} unread emails in the past {{.Timeframe}}.", 3, map[string]interface{}{
    "Person":    "Bob",
    "Timeframe": T("{{.Count}} days", 2),
})

[bubenkoff]

Why the default translation be needed if we will have the check for an untranslated strings as a console script

[bubenkoff]

Also the question to the followers: is anybody working on this ATM? If not, I'd like to work on PR

[nicksnyder]

v2 contains a proposal to fix this. See #92.

[bubenkoff]

@nicksnyder you're the man, thanks a lot!

[nicksnyder]

I just tagged 2.0.0.beta.1. Please start using it and report any issues that you have.

[bubenkoff]

@nicksnyder thanks!