Currently, Git LFS has the benefit of being a single, relocatable
binary. While it is customary to store locales in /usr/share/locales on
Unix systems, this isn't necessarily the case on Windows, and we'd like
to preserve the ability of users to move the binary where they like.
As a result, let's add a program which can be run by go generate that
embeds these translations into the binary. They are Base64-encoded to
make handling them a little easier and avoiding need to write giant
strings of backslashed escape sequences. The reader will note that this
is based off the related command to embed the manual pages.
We'd like to support localizing Git LFS. We have the gotext package,
which supports several different ways of getting GNU gettext-compatible
locale strings. However, we need some central message catalog we can
use.
Let's create a singleton by the name of Tr. That means that we can
translate a string by writing something like this:
fmt.Println(tr.Tr.Get("This is a message about %s.", subject))
These strings can be automatically extracted by the xgotext tool
available from the package
github.com/leonelquinteros/gotext/cli/xgotext. While currently quite
slow, it does understand Go syntax, unlike the standard GNU gettext
suite.
We initialize it based on the locale. Since Go does not use the
standard C library, we have to emulate its behavior, as outlined in
locale(7). If our locale is "en_DK.UTF-8", we first look for "en_DK"
and then "en", in that order. This preserves a fallback for languages
which are similar across most speakers, like English and Spanish, and
can share a translation, but for locales which cannot, such pt_PT and
pt_BR, or zh_TW and zh_CN, this ensures we prefer a more appropriate
locale.
Introduce a variable called "locales" which will be used to store
Base64-encoded MO files (compiled Gettext files) for each locale. We
can still load external locales from the standard directory
(/usr/share/locale), but this preserves the behavior of providing a
single, relocatable binary, which people like. If this becomes a
problem in the future, we can revisit it. Population of this variable
will come in a future commit.
