Add ability to split enso translations and own translations about localisation HOT 31 CLOSED

It would be a great help if you would just search for __(" and i18n(" and add the missing keys to any of the language (german).
I think there are too many keys missing - therefore I created a pull request for a new "add key" route.
To use this I think off something like this in __ in the locale.js:

       if (state.i18n[lang] && state.i18n[lang][key] != undefined) {
            //console.log("existing key: " + lang + " - " + key + " - " + (state.i18n[lang][key] || key));
            return (state.i18n[lang][key] || key);
        } else {
            if (true) { // check if we are in local env or insert a new config for localisation debug mode
                //console.log("create key: "+lang+" - "+key);
                axios.post("/api/system/localisation/addLangKey", { langKey: key }).then((response) => {
                    // xxx
                }).catch((error) => {
                    // xxx
                });
            }
            return key;
        }

Purpose:

• Check if key exists - if not add it to all languages

Explaination / missing things:

• instead of if (true) we should add something like if (env == local) or if (config.languageDebugMode == true) but I don't know how to do this

What do you think about this? If not needed I will add it to my repo and add the missing keys.

I have plans for this, in fact is one of the last few things to address, but I need to find the time for this.

I think the easiest solution would be:

• add 2 language files for each language (one master of enso, one local)
• if new keys are added add them to local file
• if keys are defined twice local is the "master" and overrides the enso key
• if new enso keys are added file is published

what do you think about this?

from localisation.

from localisation.

Just submitted a new Commit to PR.

Having 3 lang files for each language like you proposed lang/enso/xx.json,lang/app/xx.jsonand one mergedlang/xx.json`

Done!

Adding a flag to the .env / config where we can specify if we develop an enso (core) package or a project / app.

Done!

At every change from the UI the appropriate /enso.xx.json || /app/xx.json will be updated considering the above flag, and also the merged file.

For adding new keys: Done (new key gets added to the right file based on flag)
Missing: Updating existing keys. If I use the flag above all keys are added to the file. e.g. if we update app translations the core keys get added to app keys (because all keys are submitted)
Is this OK?
Other solution:

• If flag says core = true then only load and update core translations from enso folder
• If flag says core = false then check if key is changed, if yes add it to translation file in app folder

What do you think?

Having a temporary artisan command that can merge the files manually and find differences.
Done

• php artisan localisation:sync (all languages)
• php artisan localisation:sync --locale=de (only one language)

Can you please review my PR - infos and tips are welcome!

from localisation.

Yes, this is indeed a problem. But I think that the __ method expects a json in the assests/lang/ root, named "$locale.json".

What we could do here is an artisan command that will merge the lang json when needed.

• artisan localisation:sync

from localisation.

from localisation.

are there any news? I left the translation topic out in the last month, but now I would need a solution

from localisation.

And how is the process for new translations here - for example the footer line is not translated but in the localisation menu everything looks good:

I'm interested in the process how to get actual with this.

from localisation.

What do you mean by

but in the localisation menu everything looks good

from localisation.

sorry, didn't get you comment.

• In /system/localisation/editTexts all existing keys are translated to German
• but in application many translations are missing (e.g. pagination block of table)

Therefore I asked how you plan to handle this if new keys are added.

I think of something like this for new versions:

• Translations of existing keys are not replaced
• New keys are added to each language and default translation is the english value (for application wide keys for enso)
• Developer has the possibility to add new keys for his application if needed
• During build process both, the enso translations and the custom translations get merged

Do you have plans for this?

from localisation.

The problem is that not all the keys that are used in the app are also present in the localisation.

It would be a great help if you would just search for __(" and i18n(" and add the missing keys to any of the language (german). And then commit the changes in laravel-enso/localisation. You should do this from the interface, so all the languages will get the update. (keys without values).

New keys are added to each language and default translation is the english value (for application wide keys for enso)

The keys are in English, so if the translation in missing the label will be already displayed in English.

Developer has the possibility to add new keys for his application if needed
During build process both, the enso translations and the custom translations get merged

I have plans for this, in fact is one of the last few things to address, but I need to find the time for this.

In fact, we need to first think this through, to find the best approach.

from localisation.

I think that adding the auto-add-missing-keys is a really clever idea and I like it a lot. And indeed, it should work only in dev mode. We already have this flag in the front end, maybe you noticed by now the orange indicator ;)

The flag in in the vuex store under the meta object.
meta.env === 'local'

If would be great if we could figure out a mechanism to sanitize the lang files against wrong keys. Often I find myself renaming the labels, and in this case we would have leftovers (we already have some). It's not a must to have this safety mechanism, but it would be better if we did.

Regarding the second part, the __ helper that we use on the server side is Laravel's native implementation for jsons, and last time I checked it could only work with one file per locale. Did something got updated in this area?

from localisation.

ROTFL, what can I say, seems like something to improve on my side :)

from localisation.

I think that adding the auto-add-missing-keys is a really clever idea and I like it a lot. And indeed, it should work only in dev mode. We already have this flag in the front end, maybe you noticed by now the orange indicator ;)

added the check for env === 'local' and created a PR for locale.js in core repo.
if ok can you please merge the two PR and open all default pages in your local env to get the new keys. Then please commit the new files to localisation package and ask the translators to update them.
(I have not checked out an "empty" enso package, otherwise I could do this - if I start this with my version you get my keys too)

If would be great if we could figure out a mechanism to sanitize the lang files against wrong keys. Often I find myself renaming the labels, and in this case we would have leftovers (we already have some). It's not a must to have this safety mechanism, but it would be better if we did.

I don't have any idea how to achieve this because you never know which translations are used (because not all keys are used on one page). I think the only way to do this is a manual cleanup :(

Regarding the second part, the __ helper that we use on the server side is Laravel's native implementation for jsons, and last time I checked it could only work with one file per locale. Did something got updated in this area?

I checked it too and there is nothing updated in this area :(
Maybe this can help us (did not read the article): https://medium.com/@serhii.matrunchyk/using-laravel-localization-with-javascript-and-vuejs-23064d0c210e

Other solution:

• Create 2 files lang/enso/de.json and lang/app/de.json
• After changing keys in frontend merge both files and create the lang/de.json (or better merge all lang files - enso, app and the native laravel ones)
• After composer update to the same

What do you think?

from localisation.

I think it could work out.

• Having 3 lang files for each language like you proposed lang/enso/xx.json, lang/app/xx.json and one mergedlang/xx.json`
• Adding a flag to the .env / config where we can specify if we develop an enso (core) package or a project / app.
• At every change from the UI the appropriate /enso.xx.json || /app/xx.json will be updated considering the above flag, and also the merged file.
• Having a temporary artisan command that can merge the files manually and find differences.

from localisation.

Adding a flag to the .env / config where we can specify if we develop an enso (core) package or a project / app.

For me it's not clear why we need this flag?

Rest is clear - if I have time I will start with this in the next days.

from localisation.

What do you think about this?
https://www.npmjs.com/package/merge-jsons-webpack-plugin (than we can watch the folder and build it automatically?)

from localisation.

For me it's not clear why we need this flag?

because

At every change from the UI the appropriate /enso/xx.json || /app/xx.json will be updated considering the above flag, and also the merged file.

If we develop a new package for Enso, all the new lang keys should be added to lang/enso/de.json. But if you develop your personal project, you will want the new lang keys added to lang/app/de.json.

I would prefer not to rely on external packages unless strictly necessary. Merging two localisation json is so simple anyway.

from localisation.

from localisation.

Looks good at the first sight. I will review it in detail soon.

from localisation.

from localisation.

@mauthi sorry it was a very busy day for me, sorry for the late response.

Missing: Updating existing keys. If I use the flag above all keys are added to the file. e.g. if we update app translations the core keys get added to app keys (because all keys are submitted)
Is this OK?
Other solution:
If flag says core = true then only load and update core translations from enso folder
If flag says core = false then check if key is changed, if yes add it to translation file in app folder
What do you think?

I was thinking at this, and I believe that maybe we don't want this feature to be always "on". So we can have a flag in .env and in config/enso/localisation.php, something like collectMissingKeys and the allowed values should be off, core, app. After we develop (meanwhile maybe we change 30 times some of the new labels), when we consider the new feature done, we can turn this flag to core/app and navigate through the pages, and collect all the labels. After that, just turn it off.

What do you think?

@gandesc what's your take on this?

from localisation.

Meanwhile I took another look at your implementation and I think that it's better with the core flag.

We can also implement another switch in the editTexts.vue to toggle between core and app keys when editing from the interface

from localisation.

We definitely don't want the collectMissingKeys flag always on while developing, as it's very likely we'll end up with unused keys. Also, unless I'm missing anything, we could have this flag just in the front end, there's no need for it in the backend(env) just to pass it around (we could put a switch in the settings side-bar, visible only on dev)

LE: crosspost

from localisation.

ninja, stick with one profile!

I like the idea with a switch on the settings bar.

from localisation.

from localisation.

core in BE, collect Missing in FE

from localisation.

from localisation.

Just created a new PR #25

Done:

• added switch to FE

Missing:

• add switch to config sidebar (@aocneanu can you do this?)
• test "add language"
• test full feature

Looking forward to your review.

from localisation.

I did some refactor but it still needs a lot of work and tests - @y0net.. at least it seems stable.

I added the missing logic for creating and deleting language from the interface.

I'm putting now v2.5.0. We should really test all the scenarios...

@gandesc when you have the time update the docs please.

from localisation.

from localisation.

I really don't like the quality of the refactor, so maybe we can improve it.

About testing, would be perfect. We can open a new ticket for testing and write the feedback there.

from localisation.