Frontend translation about mycorrhiza HOT 5 CLOSED

• 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

from mycorrhiza.

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.

from mycorrhiza.

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.

from mycorrhiza.

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?

from mycorrhiza.

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?

from mycorrhiza.