Language Manager [Support Thread]

[lat9]

OK, shouldn't be much of a problem.


Makes perfect sense to think about encapsulated plugins, but at the same time it opens a HUGE can of worms.
#1 do EPs support language overrides per template?
#2 where to store these language files - in the main languages directory or in zc_plugins (relative to the plugin)
#3 I'm guessing the answer to #2 would be in the plugin's own directory. How to handle this when you create a translation for the current version and a new version comes out which is now in a different directory?

An example:

/zc_plugins/EditOrders/v5.0.2/catalog/includes/languages/english/modules/order_total/lang.ot_misc_cost.php

would the new override go to

zc_plugins/EditOrders/v5.0.2/catalog/includes/languages/english/modules/order_total/responsive_classic/lang.ot_misc_cost.php

or would it be picked up from

/includes/languages/english/modules/order_total/responsive_classic/lang.ot_misc_cost.php

If the latter, beautiful because it would also solve #3

I guess I'll need to test all this out and see what happens because honestly, I have no idea - the number of EPs is ridiculously small at the moment, and most of them don't have much interaction with the frontend anyway.
BUT - if DrByte adopts the idea I mentioned and demonstrated about the Remote Plugins Installer, we might see an increase in EPs so it's definitely worth digging into it.

The language override will be picked up from

/includes/languages/english/modules/order_total/responsive_classic/lang.ot_misc_cost.php

[balihr]

OK, so...
New update (github):
- select source language for cloning
- select template you want to work on
- warning for selected language IF there's a language->template association

As for Encapsulated Plugins and their translation - I'll see what I can come up with, but any ideas are most welcome in the meantime.
I've just tested with POSM and it seems lat9 is right (who knew ) - EPs can be overridden in the main language's directory, which is great news!

[pilou2]

Great, I did not think you will implement that so quickly.
After some tests, the only problem I found was with the language drop down for the source language (when creating a language pack) that lists templates override folders, like it was for the language drop down on the left, few versions ago. It seems you reuse your old code.

For Encapsulated Plugins. I am looking into it, but I am pretty sure I will be too slow for you... ;) Override in there are more complicated.

[balihr]

Great, I did not think you will implement that so quickly.
After some tests, the only problem I found was with the language drop down for the source language (when creating a language pack) that lists templates override folders, like it was for the language drop down on the left, few versions ago. It seems you reuse your old code.

Ugh, yeah, I accidentally copied from one of my dev sources... Sorry about that, restored your code, it's much better.

For Encapsulated Plugins. I am looking into it, but I am pretty sure I will be too slow for you... ;) Override in there are more complicated.

I'm almost there, been messing with this all day today (and am probably overdosed on coffee). Should be pushing an update in about an hour or so.

[balihr]

Latest version on Github is with support for Encapsulated Plugins.

One thing I'm really not sure how to approach is cloning a language - any suggestions on how to handle Encapsulated Plugins during cloning? Should we even be doing it?

If we're cloning a language, we could in theory collect all language files from zc_plugins and clone them there in the encapsulated plugin's directory, but what happens if a new version of that plugin is installed later? Let's take EditOrders as example - how to handle it when 5.0.3 is out our current 5.0.2 directory is ignored?
We could immediately do overrides in current template's directory for the frontend files, but what about admin? My gut is telling me to just leave it be...

[lat9]

Latest version on Github is with support for Encapsulated Plugins.

One thing I'm really not sure how to approach is cloning a language - any suggestions on how to handle Encapsulated Plugins during cloning? Should we even be doing it?

If we're cloning a language, we could in theory collect all language files from zc_plugins and clone them there in the encapsulated plugin's directory, but what happens if a new version of that plugin is installed later? Let's take EditOrders as example - how to handle it when 5.0.3 is out our current 5.0.2 directory is ignored?
We could immediately do overrides in current template's directory for the frontend files, but what about admin? My gut is telling me to just leave it be...

Hmm, I'm not sure what direction should be taken but I've got your questions in my head now so I might have a suggestion (or two) in a day or so.

[pilou2]

Latest version on Github is with support for Encapsulated Plugins.

One thing I'm really not sure how to approach is cloning a language - any suggestions on how to handle Encapsulated Plugins during cloning? Should we even be doing it?

If we're cloning a language, we could in theory collect all language files from zc_plugins and clone them there in the encapsulated plugin's directory, but what happens if a new version of that plugin is installed later? Let's take EditOrders as example - how to handle it when 5.0.3 is out our current 5.0.2 directory is ignored?
We could immediately do overrides in current template's directory for the frontend files, but what about admin? My gut is telling me to just leave it be...

I am back after a few days away from ZC.
When creating a new language pack, until now manually, or by cloning using this tool, it is the same problem. I think the new language files should be in their respective plugin language folders with the english folder (i.e. 'zc_plugins/LanguageManager/v1.00/admin/includes/languages/').
When the plugin is updated, translations need to be updated/copied again, or it will default to English. This is kind of the point of encapsulated plugins, not only for translation but for any code too, everything needs to be copied/updated. This version separation avoids some big mess that happens when files from different versions are mixed together.
Of course there are many updates where there is no language constants modifications and in these cases you have to copy language files. But if these files need to be updated, it is better to fall back to English rather than use old versions that would be saved somewhere in ZC main folders, which could lead to a 'constant missing' error or just a messy translation.

Doing some override on plugins files is another problem, but cloning a language should be as simple as copying files to a new language folder.

I think overriding plugins language files from ZC main files should be avoided, it will lead to situation where it will be very hard to maintain/update properly.

[balihr]

Well, the good thing about overrides is that it wouldn't cause missing constants because we're always loading the main file PLUS override and combining. So, if the plugin introduces a NEW constant, it will be loaded in the manager, and the previous modifications will remain the same if the key is still there. I think preserving previous changes makes sense because you don't want to keep thinking about language customization every time a plugin is updated.
I guess we could say there is a downside in case the new version removes a constant, but it remains "hanging" in the override file, but to be honest, this is a problem I can live with.

Let's take Edit Orders as example (which is a great example because it's very popular): you have MODULE_ORDER_TOTAL_MISC_COST_TITLE which you customized and it's now called "Location Fee". If you update the plugin to v5.0.3, you want to keep the same title for this plugin, you don't want to go and customize it again. Now imagine a plugin with 50-60 constants - do you really want to do it all over again?

Frontend language files are not a problem in this case because the system will use frontend language from zc_plugins/5.0.3 and will combine it with any overrides in root/includes/languages/xyz...

What I am concerned about is the language files that would now go missing after the new version is installed. Take this scenario for example: you have EO 5.0.2 and only English language. You use the clone tool to duplicate a language (Spanish) and the tool creates all the plugin's language files in
zc_plugins/EditOrders/v5.0.2/admin/includes/languages/spanish
and
zc_plugins/EditOrders/v5.0.2/catalog/includes/languages/spanish
Two weeks later you install EO 5.0.3. All files that were created earlier are no longer valid and you've lost ALL language files for EO in Spanish. Will the plugin fallback to English OR will it fail completely in Spanish because of missing constants?

This issue actually extends to manually installed plugins as well - you could install a plugin that only comes with English language files, meaning you'd need to manually create the file for any other language.

I'm thinking of adding a "Run Diff" button - basically compare files for the selected (target) language against english (reference) and see if any language files are missing, and if so, create them in their matching locations. So, the action would have to get a list of all admin and frontend language files, including zc_plugins, from the reference language, and compare if they exist in target language and clone them if not. Quite a complex action, but I think it can be done. However, I currently don't see a way of automating this so user would probably have to run it manually each time after installing/updating any plugins.
Any thoughts on this approach?

[pilou2]

...Will the plugin fallback to English OR will it fail completely in Spanish because of missing constants?

My understanding and experience about this is that it will fallback to English when language files are missing. I have a few multilanguage test ZC installed and when I add some plugins with only English files, there is no problem, display for these plugins is in English instead of the actualy selected language.

[pilou2]

I'm thinking of adding a "Run Diff" button - basically compare files for the selected (target) language against english (reference) and see if any language files are missing, and if so, create them in their matching locations. So, the action would have to get a list of all admin and frontend language files, including zc_plugins, from the reference language, and compare if they exist in target language and clone them if not. Quite a complex action, but I think it can be done. However, I currently don't see a way of automating this so user would probably have to run it manually each time after installing/updating any plugins.
Any thoughts on this approach?

Huum yes, when cloning from a language other than English, some files might be missing... Could this "Run Diff" button be actually the "Clone Language Pack" button? You would make a list of copied files then, at the end do the comparison/copy of missing files.