Localisation framework to cover official resources

multitheftauto / mtasa-resources

This project maintains a list of up-to-date resources that come with Multi Theft Auto.

https://multitheftauto.com

MIT License

153 stars 157 forks source link

Localisation framework to cover official resources #361

Open Dutchman101 opened 3 years ago

Dutchman101 commented 3 years ago

All official resources in this repository (except for hedit - see relevant comment) target the English language only, but we can do much better due to the variety of players from different countries MTA attracts, including to servers that use default resources.

We will set a goal of creating/implementing a localisation framework that extends to as many resources in mtasa-resources as possible, ideally using a web-end like https://translate.mtasa.com/ for a community translation effort.

Additional context

once the localisation framework is done, see about replacing the custom one in hedit with the global one
Due to the lack of a system for updating official resources with custom localisation, for now it is suggested to make the exceptions that are described in PR 359#comment

Disinterpreter commented 3 years ago

Good idea! But I think we need more data, like:

How it can be connect with another resources?
Is there an example of files(with different languages) which Pootle support?

P.S I think my questions are better for different issues or for the discussion.

patrikjuvonen commented 3 years ago

FYI, I think we still have an unused open-source license for Crowdin https://crowdin.com/, which is much better than our current Pootle setup.

Inder00 commented 3 years ago

Good idea! There is a lot work with translations (for ex. hedit).

ricksterhd123 commented 3 years ago

I have a few stupid question regarding this. Maybe I don't quite understand what you mean by framework.

Is there a relatively nice way to get the language which the user has set in MTA? I feel it would make more sense to wait for this functionality (unless it's already available) rather than using other methods such as time/keyboard layout to determine which language to use.
How does each resource share this framework? Will we use exports or just add the files to each and every resource? If one change is made in the framework then all other versions will need changing too if we choose the latter. It seems to make sense to use exports but I'm really not a big fan.

It probably makes more sense for MTA to provide functionality (assuming that this does not exist already - I did breifly check the wiki) to get the user's selected language in-game. This way we wouldn't need a framework, instead we just do similar to what hedit is already doing but for all the other scripts in a consistent way.

xLive commented 3 years ago

Is there a relatively nice way to get the language which the user has set in MTA? I feel it would make more sense to wait for this functionality (unless it's already available) rather than using other methods such as time/keyboard layout to determine which language to use.

Yes, getLocalization

Vampiiree commented 3 years ago

This is definitely a brilliant idea and I look forward to helping with translations. I even spoke to ricksterhd123 yesterday about the possibility of having other languages added to hedit.

jlillis commented 3 years ago

I had some ideas about support for resource translations but didn't think there would be enough interest to get something implemented. A proper framework would require changes to mtasa-blue to support things cleanly. My idea:

1 - Resources define translation files via meta.xml - in the case of GNU gettext (i.e Pootle) standard, this would be .pot and .po files. 2 - Client automatically downloads the "default" translation file and the translation file matching their system locale. 3 - Scripts can access translated strings within scripts via new functions. gettext(string, locale) for example.

For official resources, we would just want to agree on naming conventions and file/folder layouts so we can just point Pootle/Crowdin/whatever platform at the translation files.

Fernando-A-Rocha commented 5 months ago

I had some ideas about support for resource translations but didn't think there would be enough interest to get something implemented. A proper framework would require changes to mtasa-blue to support things cleanly. My idea:

1 - Resources define translation files via meta.xml - in the case of GNU gettext (i.e Pootle) standard, this would be .pot and .po files. 2 - Client automatically downloads the "default" translation file and the translation file matching their system locale. 3 - Scripts can access translated strings within scripts via new functions. gettext(string, locale) for example.

For official resources, we would just want to agree on naming conventions and file/folder layouts so we can just point Pootle/Crowdin/whatever platform at the translation files.

10/10 this seems like the best solution