Elaborate on the future of the LangLibs.

[Zoriot]

The current state of LL itself is not optimal. Parts like the exposed API are currently substandard and would need redesigning.

Another question is whether this makes sense when you can just use the Adventure Global Translation System (https://docs.papermc.io/adventure/localization/).

The only feature I can see at the moment is the ability to use a different language for LL plugins than for the client. I'm not sure if this feature justifies the maintenance burden that the system currently introduces. Other things, such as the language selection menu, could also be considered.
One other issue, which only affects a small number of plugins, is that you cannot query the player's language when they are offline. This could easily be fixed by storing the language on the player PDC.

The current flaws in LL:

• Highly dependent on Paper
• Requires Standalone plugin
• Language Selection in own plugin
• Requires LL Code Changes when a plugin want's to support a new language cleanly
• Uses Config Version
• Only supports yml
• Implementing it fully shaded is rather complicated - Morpheus can tell more about that
• Only a few plugins (all Alps plugins) supports it
• If another language is selected it creates a weird mix of different languages
• See the open issues for more context
• Limited Component Support
• No support for mini msg or additional functions like placeholders

We could also rework many parts of LangLibs and use Adventure internally. That way, we could probably have a nice API, but it would require quite a lot of work without much gain. If we do that, we should also prioritise DazzleConf support.

Based on the information I have, I currently favour abandoning LangLibs and switching the plugins to Adventure itself.

For now, I want to seek other input. It's important to come to a decision quickly because other time-critical things, like BuildTheEarth/BuildTeamTools#30, depend on it.

[DonatiFilippo]

Over the past few weeks, I held a series of consultations with several BTE teams regarding various development projects currently in the pipeline. A recurring point across many of these discussions was that the ability to use a plugin language independent of the server language, as well as the ability to programmatically set that language, is considered crucial for adopting these systems.

This feedback makes me lean toward keeping LL alive and expanding it to support Adventure as well. That said, doing so would undoubtedly increase the development and maintenance burden.

Perhaps we should consider rewriting LL as a v2.0, addressing the main issues that have been highlighted so far while also enabling important features such as dynamic localization.

I would also be in favor of ditching the paper plugin version of it, and make it mainly a library, in order to make maintainability easier.

[Zoriot]

What are the reasons why setting the Language for BTE/LangLibs differently then the Client Language is crucial?

I think it's also a user experience problem. Because you end up with mixed languages.

[kyanvde]

I agree with Zoriot. Having the language always match the client language is better for the user experience, as it prevents mixed languages.

Discontinuing LangLibs would also allow us to use Adventure’s localization system directly in the plugins themselves, meaning we wouldn’t have to maintain a separate localization library on top of Adventure.

[Redstoner507]

In my opinion, Adventure would be the better direction rather than continuing to maintain a library mainly to preserve the current system. Migrating to Adventure would allow us to build on a cleaner foundation with a more maintainable solution.

[DonatiFilippo]

I agree with Zoriot. Having the language always match the client language is better for the user experience, as it prevents mixed languages.

Discontinuing LangLibs would also allow us to use Adventure’s localization system directly in the plugins themselves, meaning we wouldn’t have to maintain a separate localization library on top of Adventure.

Tbh, from an user experience prospective, it seems to be better to allow for mixed languages, as I was told in a discussion with an UX designer from our team. In general mixed language is bound to happen, unless you support all languages (that is not a credible thing), so in terms of user experience the better solution would be to allow the user to select their preferred plugin language instead

[DonatiFilippo]

It also allows for in game language selections thru menus, or different localization based on language availability. Additionally, I want to point out that most people keeps their language to English, but would rather make use of plugins in their native language

[Zoriot]

So as far as I understand the situation is that.

• Industry standard is using Adventure
  • Just passing through a TranslatableComponent through sendMessage
  • Client Side Language Language = Server language
  • Using normal Java Language fallbacks
  • if non is found falling back to the pack default e.g en-US
  • Paper doesn't support that for items at all
  • It allows you to register the language server side

This is fine as a default (except no item rendering) but especially for bte has some problems.

Examples:

• Players want to use English for Minecraft itself but their local message for more complicated things
• Players have a language like Hebrew, Chinese or Arabic which is not nicely supported anywhere

For overcoming these problems it's important to have the option to set the language more gradually. We should still use Adventure where possible to reduce overhead.

We have multiple ways to do it, some require additional testing before:

1. Have a Extension to Player like sendLangLibsMessage which then uses custom LL player resolving
2. Don't use the GlobalTranslation store and use a event to detect untranslated (custom) messages and then translate it manually
3. Hook into Events to get the message before Global Translator resolved it and if smt diffrent is set resolve the message we want. That would also work for non LL Plugins which uses Adventure + Global Translator - but not sure if such an event really exists. In that case we also would need some way to define which plugins get translated via the player set language.

I think 1. would be nice because it would make LangLibs completly optional.

The question also is, if it's not a completely independent implementation how we want to ship LL in the future, currently the paper (soon also velocity) companion plugin were requirement. I think there should be a minimal shaded dependency which just falls back to client language / default Global Translator if LL is not installed for things like T+- where we don't want any dependency.

We could also have another package which provides a full implementation. Not sure rn if that's really needed - might be useful for plugins like BTT though.

Generally I could be worth to allow more gradual control over what language should get used when for both servers and users.

Maybe also alternative storage methods like SQLLite, H2 or data container.

Another thing we have to consider is that we cannot use default Minecraft Translation anymore at this point else we would mix languages in a single message. We could work around that with registering the Minecraft languages in the Global Translator or our own.

For items we probably always have to have some sort of lib to resolve them/render the component.

General Infos (idk if I linked them before):

• https://docs.papermc.io/adventure/localization/
• https://docs.papermc.io/adventure/minimessage/translator/

New plugins currently should probably use the Global Translator for now and render items themselves as long this is not implemented.

Generally this is the right way to continue on that, at the same time I fear we currently have not the proper resources for a proper implementation rn.

[kyanvde]

It seems like you can pass a locale of choice to adventure and you are not locked into using the locale set by the client, so wouldn't this solve the issue of not being able to select a language ingame?

[Zoriot]

@kyanvde that's option 1, you then still need to resolve the language yourself

[Cinnazeyy]

Thank you everyone for your elaborate comments.
First of all, I agree that that the current state of LangLibs is suboptimal and a lot needs to change.

In my opinion the option to decouple server language and client language, while still seamlessly changing the displayed language across all plugins over multiple servers that use the system at once seamlessly, are crucial and are why LangLibs was created in the first place.
Like @DonatiFilippo already mentioned, most people dont change their client language. Many non native English speakers for example might be totally fine with having the game entirely in English, but then struggle to understand more technical and detailed text from plugins like the PlotSystem. This is especially apparent with the PS tutorial, but is a reacurring pattern I have noticed both on our own server, as well as talking with other BTE server owners.
BTE in general is a quite complex and linguistically diverese project, that therefore often doesnt fall neatly into the "industry standard".
This decoupling alone justifies the existance of LangLibs into the future for me.

Like @Zoriot already mentioned, you can achieve a similar system using Adventure, but you would still need to have a system above it that centralises language choices per user, instead of simply getting the client locale.
I am generaly open to explore this route as well, and rework the internals of LL to use adventure's system for the actual rendering/serving translations, wherever it makes sense.

Implementing some kind of additional layer before the LangUtils.getInstance().get(...) to fall back to an alternative non-LL solution, whether thats an extension or another method in the LangUtils or something else entirely is imo a good idea.
Its already something you can do quite trivially inside a plugin that depends on LL, since all the actual translations live inside that plugins scope anyways, but im open to making it easier or work better with a just adventure solution.
Ultimately tho, LL should primarily focus on the LL part, and I see fallbacks more as the responsibility of the plugins that implement LL, rather than inside LangLibs itself.

As for alternative storage methods, this is already something that was being worked on by me and @DonatiFilippo , in a similar vain to how the Velocity support or the DataProviders of the PS work.