i18n support [WIP]

[uaktags]

Just in case it's seen here before github, but I started this PR to include i18n support:
https://github.com/ChristopherDay/Gangster-Legends-V2/pull/53

translations files are available for both Modules and for the engine itself as a whole:
https://github.com/ChristopherDay/Gangster-Legends-V2/blob/5e668b79548b2aa1c439493dcd95be391a1c4870/locale/en/translation.json
and 
https://github.com/ChristopherDay/Gangster-Legends-V2/blob/5e668b79548b2aa1c439493dcd95be391a1c4870/modules/installed/loggedin/locale/en/translation.json

I took https://github.com/Philipp15b/php-i18n and modified it to support an array of languages and fixed up its usage of vsprintf to allow for dynamic parameters for translation. I opted against composer for this since 1) GL doesn't use composer packages, everything is just self-contained, and 2) i heavily have been modifying it and the project seems mostly dead anyhow (the php-i18n project).

Full Disclosure: (I'm one of the guys who use to manage ezRPG...RIP to that project, though I wish I'd brush the dust off and get 'er up and going again). 

[Dayo]

I’ve only sparingly looked through the code I’m just wondering if this is a overly complex way of doing this, by the looks of it loads JSON files then generates PHP code.

I have been thinking how to do this for a while. I planned on adding language translations within the module.json file then adding the translation logic within the page class so you could do something like $this->page->translate(“crime.successText”); or if you was in the tpl.php file {translate crime.successText}

[Sim]

The best way for translation is still language filrs.

$lang['crime'] = "Crimes*;

$lang["crimeSuccess"] = "Message to display to user upon successfully commiting crime";

Even larger scripts still use this method. This forum itself does.

[Dayo]

2 hours ago, Sim said:

The best way for translation is still language filrs.

$lang['crime'] = "Crimes*;

$lang["crimeSuccess"] = "Message to display to user upon successfully commiting crime";

Even larger scripts still use this method. This forum itself does.

Both the method I suggested as well as uaktags suggested use language files, but by having them in JSON rather then php any language with a JSON parser can read them.

[ags_cs4]

4 hours ago, Dayo said:

Both the method I suggested as well as uaktags suggested use language files, but by having them in JSON rather then php any language with a JSON parser can read them.

yup they are always the best way and at the same time it will be faster and wont use resources of the site

[uaktags]

I'm not sure I quite understand the "adding language translations within the module.json file". Granted I've only spent a whopping 2-3days looking at the project that you've created and supported for years, so my opinion is pretty narrow-minded in the grand scheme, but I took the module.json as having a single purpose for module meta, rather than providing functionality. Localizations are, in my experience, always separate files rather than a combined file.

As for the JSON => PHP layer, that's merely the caching aspect. Basically all of the json's get loaded once in a single taxing moment (taxing being relevant), and cache as a PHP file that is read by the PHP project. Now my implementation is pretty much a quick and dirty, so it checks every single request (due to init.php) against the cache, but surely it could be restricted to an event like "module installation" or some admin function.

As for being able to call it with the proposed translate function, you can already do that. L:: is available in hooks, modules, and inc files. You can change the logic around the use of L:: to your translation or {translate} idea, but that's really just semantics imo. The only thing I think i currently lack is the {translate} access without a BuildElement call. There's also obvious things that the original package itself was missing too (handling of missing translation strings for one), but for a proof of concept, think it stepped up pretty nicely.

Either way, hope that helps inspire to get localizations built and adopted in whatever form is deemed. Goodluck with everything. 

[Dayo]

so my idea was to do something like this:

{
    "name": "Crimes",
    "version": "1.0.0",
    "description": "This module allows a user to commit crimes.",
    "author": {
        "name": "Chris Day",
        "url": "http:\/\/glscript.cdcoding.com"
    },
    "pageName": "Crimes",
    "accessInJail": false,
    "requireLogin": true,
    "adminGroup": "Game Mechanics",
    "admin": [
        {
            "text": "View Crimes",
            "method": "view"
        },
        {
            "text": "New Crime",
            "method": "new"
        },
        {
            "hide": true,
            "text": "Edit Crime",
            "method": "edit"
        },
        {
            "hide": true,
            "text": "Delete Crime",
            "method": "delete"
        }
    ], 
    "lang": {
        "en": {
            "successText": "Success", 
            "faileText": "Failed"
        },
        "de": {
            "successText": "Erfolg", 
            "failedText": "Gescheitert"
        }
    }
}

I am working on caching all of the module.json files at the moment so all of the language files would be included within the cache.

[Sim]

Including th lang keys inside the json files was actuality better then what I had in mind. Simple and not effective.

 

I dislike the idea of using it at all though. GL is a small engine not used or advertised much. As one of the most active mod developers, it's just to much  extra work to use language refrences in a json file and inside the code. I have a hard enough time remember my PHP variables the majority of the time. No I got to remember language keys. :). My IMO.

[Dayo]

14 minutes ago, Sim said:

Including th lang keys inside the json files was actuality better then what I had in mind. Simple and not effective.

 

I dislike the idea of using it at all though. GL is a small engine not used or advertised much. As one of the most active mod developers, it's just to much  extra work to use language refrences in a json file and inside the code. I have a hard enough time remember my PHP variables the majority of the time. No I got to remember language keys. :). My IMO.

The idea is to add support early on so that when you want it later it's easy to add. Mod developers like yourself can always not use this functionality and hard code strings. But by having the option people can always contribute translation files that then open up the game/engine/mod to other markets.

Once multi language support is added mod developers will not have to use it but it's there for those who do. And any modules that are supported i would make a nice UI so that new language files can be added by 3rd parties.

At the end of the day you should be able to install a module without ever having to open up a code editor, currently if you want a different language (there are 3 GL games i know of at least that use different languages) you have to go in and edit code directly potentially causing issues for developers in the long run when you want to release a bug fix..

Edited October 3, 2020 by Dayo

[Sim]

The feature there is nice. And maybe bring more GL supporters.

I think the JSON structure isn't the best idea, I still screw them up making my module.json files. I believe there has to be an easier way that follows the same concept without all the brackets and commas.

[Dayo]

23 minutes ago, Sim said:

The feature there is nice. And maybe bring more GL supporters.

I think the JSON structure isn't the best idea, I still screw them up making my module.json files. I believe there has to be an easier way that follows the same concept without all the brackets and commas.

If you find generating the module.json difficult i can always make a tool to generate it.

[Sim]

I usually copy paste and make changes or copy file and make changes. There's been quite a few times I couldn't fix some Little syntax error and just started the file over  loo