Explain localization

[zml2008]

We have a basic localization system within Adventure, using TranslationRegistry

There should be a documentation page explaining it, how it interacts with vanilla translations, and its limitations.

Limitations include:

• no specialized number formatting
• relies on client sending its language to the server
• plural handling

This could mention moonshine, and potentially whatever is added to MiniMessage for localization

[vintprox]

Personally, I'm looking towards this (with some obsession, apparently). 🤯

Regarding the limitations you listed...

• Given MessageFormat is used for translations, are we to assume that it has no specialized number formatting?
• If client's language is lost, does it fall back to keys from default locale (if any) or show keys in red?
• Plurals are really something, alright. Not only that the semantics are different between languages, but also that it requires separate keys for each notation. Even if library had number range checks, user code has to be coupled with per-language logic.

By the way, what are prospects of gettext integration? "Portable Object" is already an advantageous syntax for translators: with integral plurals logic, comments and flags. I guess that I should use gettext-commons for this. Just wanted your take on this.

[zml2008]

1. TranslatableComponent can only take other Components as arguments
2. default locale -- missing keys don't ever receive extra formatting
3. yup!

I've tried doing gettext formatting in java projects years back -- the biggest bottleneck was iirc the need for something to generate pot files -- I had a fork of gettext-maven-plugin at https://github.com/zml2008/gettext-maven-plugin, not sure if anything similar exists for Gradle.

To do localization properly, I still think you'd need some sort of wrapper around Components, since components can't really serialize the arbitrary types that could be part of a MessageFormat.

[vintprox]

Thanks for your observant response, @zml2008.

There is gettext-plugin for Gradle with *.pot generation, format and merge tasks. Didn't try it myself yet, but I hope it's something.

If I'm not wrong, gettext is already one heck of a task for someone's pipeline, with ahead-of-time compilation and whistles. So, I'd understand if it wouldn't have a spotlight in docs. While gettext is awesome for internationalization, it doesn't cover l10n much (especially if we talk about serialization of arbitrary types in Java, as it probably shouldn't anyway).

[nathanfranke]

Perhaps support can be added for choice formats in MessageFormat?

Example:

import java.text.MessageFormat
fun main() {
    for (i in 1..5) {
    	println(MessageFormat("There {0,choice,1#is|1<are} {0,number,integer} {0,choice,1#player|1<players} connected.").format(arrayOf(i)))
    }
}

Output:

There is 1 player connected.
There are 2 players connected.
There are 3 players connected.
There are 4 players connected.
There are 5 players connected.

Playground:

https://play.kotlinlang.org/#eyJ2ZXJzaW9uIjoiMS45LjIyIiwicGxhdGZvcm0iOiJqYXZhIiwiYXJncyI6IiIsIm5vbmVNYXJrZXJzIjp0cnVlLCJ0aGVtZSI6ImlkZWEiLCJjb2RlIjoiaW1wb3J0IGphdmEudGV4dC5NZXNzYWdlRm9ybWF0XG5mdW4gbWFpbigpIHtcbiAgICBmb3IgKGkgaW4gMS4uNSkge1xuICAgIFx0cHJpbnRsbihNZXNzYWdlRm9ybWF0KFwiVGhlcmUgezAsY2hvaWNlLDEjaXN8MTxhcmV9IHswLG51bWJlcixpbnRlZ2VyfSB7MCxjaG9pY2UsMSNwbGF5ZXJ8MTxwbGF5ZXJzfSBjb25uZWN0ZWQuXCIpLmZvcm1hdChhcnJheU9mKGkpKSlcbiAgICB9XG59In0=

[kezz]

I'm going to close this as decently enough completed by #205