Unclear workflow when missing translations

[krishicks]

Given I've added a string to the translations for the default language and run goi18n *.all.json to update the other languages with the new id without a translation, my program is now in a state where it will return ids for all non-default languages rather than something intelligible, like the value present in the default language.

The README explains that you're meant to send out the *.untranslated.json files for translations after running goi18n *.all.json, but am I supposed to wait until I get those translations back before I can ship my code?

It would be far more preferable if I could use a default language for when a translation does not exist.

It seems to me that this is not presently possible with go-i18n. I have to merge the untranslated translation files (which contain the default language), which means then that the untranslated files get emptied. Now I cannot easily add another string as my untranslated files will then only contain the new untranslated string.

I would like to be able to maintain untranslated files with all of the untranslated strings such that whenever I get a chance to send them out I have the complete list, and have a default language used when a specific translation ID does not exist.

[nicksnyder]

You are the second person to bring this up so I will think about it some more.

In the meantime, you should be able to just wrap your Tfunc in another function to make the fallback behavior explicit.

Something like this (pseudocode, not tested)

func MyTfunc(pref string, prefs ...string) TranslateFunc {
    t := i18n.MustTfunc(pref, prefs...)
    return func(translationID string, args ...interface{}) string {
        if translated := t(translationID, args...); translated != translationID {
            return translated
        }
        return i18n.MustTfunc("en-US", args...) // assuming en-US is your "default" locale
    }
}

[krishicks]

Thanks, I'll give that a shot. I'll report back on any performance penalty I see with that approach.

[coreyhulen]

We ran into the same problem. A global fallback would be great since something is better than nothing.

[krishicks]

@coreyhulen You can see our implementation of @nicksnyder's suggestion above here: https://github.com/cloudfoundry/cli/blob/master/cf/i18n/i18n.go#L59

[coreyhulen]

thanks @krishicks

[nicksnyder]

v2 includes a proposal to perform fallbacks on a per-message basis. See #92

[nicksnyder]

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