Gettext has everything, it just takes knowing five languages to understand what to use for

Sharlin 5 hours ago | parent | prev | next [-]

Yeah, some sort of pluralization support is pretty much the second most important feature in any message localization tool, right after the ability to substitute externally-defined strings in the first place. Even in a monolingual application, spamming plural formatting logic in application code isn't exactly the best practice.

▲

iririririr 4 hours ago | parent | prev [-]

gettext have everything, plus a huge ecosystem like tools to coordinate collaboration from thousand of contributors etc.

if alternatives don't start with a very strong case why gettext wasn't a good option, it's already a good indicator of not-invented-here syndrome.

▲

moltonel 3 hours ago | parent [-]

It's not hard to make a case against gettext, despite its maturity and large ecosystem.

IMHO pluralization is a prime example, with an API that only cleanly handles the English case, requires the developer to be aware of translation gotchas, and honnestly confusing documentation and format. Compare that to MessageFormat's pluralization example (https://github.com/unicode-org/message-format-wg/blob/main/s...) which is very easy to understand and fully in the translator's hands.

▲

vsl 2 hours ago | parent [-]

> IMHO pluralization is a prime example, with an API that only cleanly handles the English case

That’s not true at all? Gettext is functionally limited to source code being English (or alike). It handles all translation languages just fine, and competently so.

What is doesn’t have is MessageFormat’s gender selectors (useful) or formatting (arguably not really, strays from translations to locales and is better solvable with placeholders and locale-aware formatting code).

> fully in the translator's hands.

That is a problem that gettext doesn’t suffer from. You can’t reasonably expect translators to write correct DSL expressions.

	▲	moltonel 6 minutes ago \| parent [-]
		> Gettext is functionally limited to source code being English (or alike). It handles all translation languages just fine, and competently so. The *ngettext() family of functions take two strings (typically singular/plural) and rely on a language-wide expression to choose the variant (possibly more than 2 variants). There's no good reason for taking two strings, this should be handled in the language file, even without a DSL. Ngettext handling a single countable makes some corner-cases awkward, like gendering a group with possibly mixed-gender elements. The Plural-Forms expression not being per-message means that for example even in English "none/one/many foo" has to be handled in code, and that a language with only a rare 3rd plural has to pay the complexity for all cases. Arguably, those are all nitpicks, Gettext is adequate for most projects. But quality translations get cumbersome very quickly. > You can’t reasonably expect translators to write correct DSL expressions. This feels demeaning. Translators regularly have to check the source code, and often write templates, they're well able for a DSL like MessageFormat's, especially when it's always the same expressions for their language. It saves a trip to the bugtracker to get developers to massage their code into something translatable. You can't reasonably expect a English-speaking developer armed with ngettext to know (and prepare their code for) the subtleties of Gaelic numerals.