Locale improvements #21

New Issue

Exynox · 2024-04-07T10:19:11+03:00

Exynox commented

2024-04-07 10:19:11 +03:00

Change locale_service.cpp so that the proper locale_string file is automatically read
Remove the locale/country_here/ strings, in order to uniformly treat all locales
Remove locales for unsupported countries
Make GF/EU the default behaviour

- Change locale_service.cpp so that the proper locale_string file is automatically read - Remove the locale/country_here/ strings, in order to uniformly treat all locales - Remove locales for unsupported countries - Make GF/EU the default behaviour

Exynox added the

enhancement

label 2024-04-07 10:19:11 +03:00

Tr0n commented

2024-04-07 13:21:28 +03:00

Make GF/EU the default behaviour

Do you still want to keep all the local variation in the code? Or should that all be removed?

Remove locales for unsupported countries

Change locale_service.cpp so that the proper locale_string file is automatically read

Remove the locale/country_here/ strings, in order to uniformly treat all locales

So you want to keep supporting some locales? Or do you want to yeet everything that's not English?

> - Make GF/EU the default behaviour Do you still want to keep all the local variation in the code? Or should that all be removed? > - Remove locales for unsupported countries > - Change locale_service.cpp so that the proper locale_string file is automatically read > - Remove the locale/country_here/ strings, in order to uniformly treat all locales So you want to keep supporting _some_ locales? Or do you want to yeet everything that's not English?

Exynox commented

2024-04-07 18:15:55 +03:00

Sorry for the confusion, this was more of a rudimentary list so I had a rough idea what I should do.

Make GF/EU the default behaviour

Do you still want to keep all the local variation in the code? Or should that all be removed?

I meant that the server behaviour should be the same across locales: for example, there are checks like these below that should be removed. The behaviour after removal should be identical to the one of an European, Gameforge locale. This removal should also be done on the client side.

Remove locales for unsupported countries

Change locale_service.cpp so that the proper locale_string file is automatically read

Remove the locale/country_here/ strings, in order to uniformly treat all locales

So you want to keep supporting some locales? Or do you want to yeet everything that's not English?

The plan is to support as many languages as possible, while keeping an identical game experience. Ideally, all translations will end up being client-side, by using systems such as this one: https://metin2.dev/topic/29790-official-client-locale-stringreversed/. I intend to remove the locales that present little interest (China), are no longer being published (Japan, Korea, Vietnam, Thailand), or can be replaced pretty smoothly with a GF locale (USA, Singapore). Essentially, we shouldn't have country locales, but language locales, therefore supporting Spanish from both Spain and Mexico, Portuguese from both Portugal and Brazil, etc.

Also, there are locales that were never used, such as the one for Bulgaria.

I also meant that locale_service should be changed accordingly, as to have an uniform file structure, for example:

Before:

After:

We should also push for UTF-8 strings, even though that would require some rewriting in the client, as text rendering pretty much would only work for fixed-length encodings.

Another idea I have is to encourage community translations, especially for languages that have never been supported (Serbian, Bulgarian, etc.). This would require that all localization files be on the client-side first, in an easy-to-translate format; maybe gettext? It would also be interesting to see if machine translation is passable enough in a few years so that we could do this without much human effort.

Sorry for the confusion, this was more of a rudimentary list so I had a rough idea what I should do. > > - Make GF/EU the default behaviour > > Do you still want to keep all the local variation in the code? Or should that all be removed? I meant that the server behaviour should be the same across locales: for example, there are checks like these below that should be removed. The behaviour after removal should be identical to the one of an European, Gameforge locale. This removal should also be done on the client side. ![image](/attachments/4f25181a-9075-418c-8cf7-ed1d1c7d91cf) ![image](/attachments/d51695dd-01fb-4996-9e8b-e87ece30129b) > > - Remove locales for unsupported countries > > - Change locale_service.cpp so that the proper locale_string file is automatically read > > - Remove the locale/country_here/ strings, in order to uniformly treat all locales > > So you want to keep supporting _some_ locales? Or do you want to yeet everything that's not English? The plan is to support as many languages as possible, while keeping an identical game experience. Ideally, all translations will end up being client-side, by using systems such as this one: https://metin2.dev/topic/29790-official-client-locale-stringreversed/. I intend to remove the locales that present little interest (China), are no longer being published (Japan, Korea, Vietnam, Thailand), or can be replaced pretty smoothly with a GF locale (USA, Singapore). Essentially, we shouldn't have *country* locales, but *language* locales, therefore supporting Spanish from both Spain and Mexico, Portuguese from both Portugal and Brazil, etc. Also, there are locales that were never used, such as the one for Bulgaria. I also meant that locale_service should be changed accordingly, as to have an uniform file structure, for example: Before: ![image](/attachments/6e70ca72-d4a3-44d9-bea1-04befcbabd5e) After: ![image](/attachments/1214d361-b58c-49e3-91d1-df71a6e71f94) We should also push for UTF-8 strings, even though that would require some rewriting in the client, as text rendering pretty much would only work for fixed-length encodings. Another idea I have is to encourage community translations, especially for languages that have never been supported (Serbian, Bulgarian, etc.). This would require that all localization files be on the client-side first, in an easy-to-translate format; maybe gettext? It would also be interesting to see if machine translation is passable enough in a few years so that we could do this without much human effort.

image.png

20 KiB

image.png

41 KiB

image.png

38 KiB

image.png

40 KiB

Tr0n commented

2024-04-07 19:02:14 +03:00

Phew. Glad we had the same goal (again) :D
I yeeted everything (except for 6/7 bonus, which was disabled in EU) in a branch on my fork #22.

Phew. Glad we had the same goal (again) :D I yeeted everything (except for 6/7 bonus, which was disabled in EU) in a branch on my fork #22.