Frontend translation

[chekoopa]

I've almost started to translate help documentation, when I've found out that I wouldn't be able to navigate it, as it is fixed to English. So it struck me that we probably should translate the frontend part of Mycorrhiza. I emphasize on frontend, because log messages should be left English as the most universal language.

I'm ready to self-assign to it, but I have some questions to discuss first.

My concerns are possible bloat, quicktemplate interoperation, l18n library choice, and language choice mechanism.

About the latter, we preferably should extract the locale from user's request and then fall back to English. Also, as an idea, one could set the default locale in their configuration.

About the l18n library, we have a few choices:

• gotext, which would require adding locales, which is less bloaty, as one could remove unused locales. Also, it is more general (gettext is common) and explicitly supports short codes (such as en, eo, ru).
• go-localize, which is generate-based, seemingly lean, though has to keep all the strings inside of the binary.
• go-i18n, which is the most functional and bloated. Can use external files.
• golang.org/x/text with low-level, yet flexible operation. Possibly, own i18n strings format.

BTW, x/text and gotext approaches would let us implement custom wiki-local locales.

[bouncepaw]

• i18n is not bloat
• quicktemplate interoperation won't be any issue
• as for the library, go-localize seems the coolest
  • the fact that it stores all the strings in the binary is nice

Do we need wiki-local locales? I don't think so.

The real issue with translations is that they are always outdated. It takes significant amount of work to keep them up-to-date

[handlerug]

My opinion is that gettext is the most bloaty thing I've ever seen in my life. I would prefer something simple, maybe something YAML- or JSON-based. Gettext syntax is really ugly and is almost impossible to write by hand. So I'm already negatively biased towards gotext.

go-localize looks pretty clean, I like it. go-i18n doesn't look bloaty but yeah it does have a lot of stuff. All other ones are pretty cool too.

We could even have our own i18n solution myco-style. However, I wouldn't really support front-end translations for the same reason @bouncepaw has stated.

[chekoopa]

i18n is not bloat

Seemed bloated to me.

quicktemplate interoperation won't be any issue

I have little idea how would I inject these strings. But as we're coming up with the library choice, I seem to understand a proper way for it.

the fact that it stores all the strings in the binary is nice

If you're not against that, I'm ready for code-generated solutions, like fore-mentioned go-localize. Plurals, though, would be a hot mess.

Do we need wiki-local locales? I don't think so.

Well, that was just an assumption, as some themed wikis would utilize that. It might be difficult to implement. However, there is a little dirty hack for go-localize which would let us inject wiki-local strings. :^)

The real issue with translations is that they are always outdated. It takes significant amount of work to keep them up-to-date

Fallback locale to the rescue. If something isn't translated, it falls back to English.

[bouncepaw]

We could even have our own i18n solution myco-style

I already have some dirty thoughts about that. But let's use something else (go-localize ig)

i18n is not bloat

Seemed bloated to me.

Let's consider i18n a form of accessibility. Accessibility is never bloat.

However, there is a little dirty hack for go-localize which would let us inject wiki-local strings.

What hack?

[chekoopa]

Let's consider i18n a form of accessibility. Accessibility is never bloat.

Oh, I've thought about i18n the library. I'm eagerly agree with you about the i18n itself.

What hack?

:^) go-localize generates a very neat and flexible code.

Okay, so I've heard in the dev chat about fallback locales are a bad idea. But what are alternatives?