search

magma1447 / greasemonkey-geocaching-projectgc

Adds links and data to Geocaching.com to make it collaborate with Project-GC.com
MIT License
18 stars 14 forks source link

Made the script bilingual, and ready for more translations #142

Closed cghove closed 1 year ago

cghove commented 1 year ago

Not sure if @magma1447 have considered this option before, but here's the framwork for a multilanguage script. Think I've gotten all text strings into the json files. But not sure if the translations should be done and kept here on github, or if @magma1447 maybe only want the initial pgc.en.json here to add new strings and then pull that file into whatever tool is beeing used to translate the website, and call the strings from there. The script will detect the language of the browser, and should default to English if the users language don't exist

magma1447 commented 1 year ago

I will look into this and come back with more information. More particularly I will investigate if we can use Crowdin, which is used for translating Project-GC, to translate this as well. And how cumbersome that workflow will be.

The Userscript starts of by calling the API method GetMyUsername to get some initial data. I have added locale to that data blob as well. In the future maybe the API method should be renamed since it's now returning a bunch of data beside the username. The patch to add locale isn't live yet, only in our development environment. But it can be expected to be added soon.

When added it can be used as an override for the web browsers language for example.

magma1447 commented 1 year ago

When looking into adding files to Crowdin I happened to notice that the pgc.en.json starts with the section heder, I assume it should say header (typo).

magma1447 commented 1 year ago

I have come as far as that I have added the pgc.en.json to Crowdin for translation. It's a manual step. Then when I am fetching translations for Project-GC the Userscript translations ends up as https://project-gc.com/locale/nb_NO/userscript.json (only dev yet, not in production).

The translators are fast at Crowdin and there are a few languages where most is translated already (I imported your nb_NO translations).

I am not sure which approach will be best here though. Shall we build two scripts? One for pushing pgc.en.json to Crowdin, and another to fetch translations into the Git-repository?

PS! The merge is fine to me, maybe fix that heder vs header. Then I didn't really review the code, I just trust it. So in my opinion we could merge this and then split out the process discussion in another Issue?

magma1447 commented 1 year ago

By the way, is it some best practice to have both these? Or would it be smarter to just have one in this case? They are not likely to change into different wordings?

"gallery": "Project-GC Gallery",
"gallery2": "Project-GC Gallery",

One of the Swedish translators usually notices things, and it didn't take him many minutes to find this, and question it.

cghove commented 1 year ago

By the way, is it some best practice to have both these? Or would it be smarter to just have one in this case? They are not likely to change into different wordings?

"gallery": "Project-GC Gallery",
"gallery2": "Project-GC Gallery",

One of the Swedish translators usually notices things, and it didn't take him many minutes to find this, and question it.

"gallery": "Project-GC Gallery"
"Gallery 2": "PGC Gallery"

they are supposed to be different

magma1447 commented 1 year ago 
"gallery": "Project-GC Gallery"
"Gallery 2": "PGC Gallery"

they are supposed to be different

Aha, I see now. I just saw the Swedish translation and therefore didn't realize they were different. Because of lack of pixel-space I guess.

EDIT: Or now I am just confused. Because the EN-file has the same translation on them. Was it a mistake to have the same string on them?

cghove commented 1 year ago 
"gallery": "Project-GC Gallery"
"Gallery 2": "PGC Gallery"

they are supposed to be different

Aha, I see now. I just saw the Swedish translation and therefore didn't realize they were different. Because of lack of pixel-space I guess.

EDIT: Or now I am just confused. Because the EN-file has the same translation on them. Was it a mistake to have the same string on them?

They are the same in the EN-file due to me not proofreading enough... 🙈 But in the script they are different...

cghove commented 1 year ago

I will look into this and come back with more information. More particularly I will investigate if we can use Crowdin, which is used for translating Project-GC, to translate this as well. And how cumbersome that workflow will be.

The Userscript starts of by calling the API method GetMyUsername to get some initial data. I have added locale to that data blob as well. In the future maybe the API method should be renamed since it's now returning a bunch of data beside the username. The patch to add locale isn't live yet, only in our development environment. But it can be expected to be added soon.

When added it can be used as an override for the web browsers language for example.

That would also mean that something like this need to be added to the script:

//declare the language variable as empty, in the beginning of the script
var _language = "";

function CheckPGCLogin() {
        GM.xmlHttpRequest({
            method: "GET",
            url: pgcApiUrl + 'GetMyUsername',
            onload: function(response) {
                var result = JSON.parse(response.responseText);
                _**language = response.locale; //untested code
                i18next.changeLanguage(_language);//untested code**
                if (result.status !== 'OK') {
                    alert(response.responseText);
                    return false;
                }

                pgcUsername = result.data.username;
                // Issue 113 & #133; fixed 2022-09-04 (Units of elevation obtained from Project-GC)
                imperialFlag = result.data.imperialUnits;
                loggedIn = Boolean(result.data.loggedIn);
                subscription = Boolean(result.data.subscription);
cghove commented 1 year ago

When looking into adding files to Crowdin I happened to notice that the pgc.en.json starts with the section heder, I assume it should say header (typo).

Yes a typo, but it's an invisible typo 😜 , so if that one word is changed, we also need to change all : i18next.t("heder... strings, since it's a reference variable

cghove commented 1 year ago

Not sure if it's needed but in the cachetur assistant we've added all languages we have in the translation tool to whitelist: ['nb_NO', 'en'], preload: ['nb_NO', 'en'], And I guess it's obvious, but the loadpath
loadPath: 'https://raw.githubusercontent.com/magma1447/greasemonkey-geocaching-projectgc/master/language/{{ns}}.{{lng}}.json', crossDomain: true need to be changed to where you end up storing the translations

cghove commented 1 year ago

Hmm... for some reason when i change the loadpath to match the language files on PGC loadpath: 'https://project-gc.com/locale/{{lng}}/{{ns}}.json', The script tries to load the translations from https://www.geocaching.com/locales/nb_NO/userscript.json and not https://project-gc.com//locales/nb_NO/userscript.json image

cghove commented 1 year ago

Actually got it to try to load the translations from the pgcurl. But got a cors error, not sure if that's something @magma1447 has to switch on server side?

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://project-gc.com/locale/en_US/userscript.json. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.

magma1447 commented 1 year ago

This is what I found now. I'll see if I can fix it myself in this Pull request.