ProcessWires translation system is great. But only as long as you don't want to create a module and want to ship that module with different languages. But that's a very common need, especially if you are not native english and the default language of your module is for example german.
Current vs. suggested behavior
Translations of a module should really be where they belong: Inside the module. If the module changes, the translations change as well.
Why would the enhancement be useful to users?
Imagine you created a module for SEO and you install it on every site that you create for your clients. All your clients speak german, so you translate your module to german.
One year later you have created 10 sites and you update your SEO module and of course you need to update translations for it. But it's not enough to just pull the new module version, you also need to update 10 site translations by hand.
Oh, you got 100 pages using your module? That means 100 manual translation upgrades. Lets say you change 3 strings in each 2 files, that means 2x(3+2) = 10 clicks. So for all your translations that's 100x10 unnecessary clicks. Now imagine your module is used by many people on the world... that means how many clicks? No, I don't want to imagine that :)
One could of course also copy the translation files, but I'm not sure if that would be really quicker, because the language IDs are different on every install so you'd need to be really careful what you are doing and that makes you slow again...
while just being occupied with Processwire's multi-language support, this question came to my mind: Is there already some mechanism established to deliver translations with a module?
When developing a module, you can make the module support multi-language by using __() etc. Is there a way / standard to add some language .json files to the module folder for ProcessWire to import automatically?
Recently I launched a module -ImportPagesPrestashop-, and now I was thinking if it is worthy to translate this module in several languages (starting with a translation in dutch, because I'm from the Netherlands).
I once asked Ryan if he plans to add language files to his Pro modules. He doesn't plan to do so. His reply was (more or less) that most people using these modules were developers, not authors (clients), and a developer surely understands English. Fact is, many of the Pro modules are not only being used by superusers, so that's kind of a weak excuse. It's a lot of work translating e.g. a Lister Pro language file. Of course, for German, I only did it once, and then copy files over. Other eco-systems have solved this way better imho...
In the past I've worked with a few translation platforms (Launchpad, Twitter translation center, translate.wordpress.org, etc. — there are plenty of good examples) and one of the projects on my "things I want to do as soon as I find the time" list is a similar platform for ProcessWire.
The way I envision this working would be a shared service (website, essentially) where translators can register and do pretty much the same thing they would do in the translations screen in Admin, and then share those projects with others who can both use them and contribute (obviously after an approval process). This would likely be split into "projects" (core, individual core or third party modules, site profiles, etc.)
For the site you'd still need a module to install these translations, but the main concept here is a common library of translation files that would do most of the heavy lifting and provide an API for the module. I've been struggling a lot trying to keep up with who manages which translation for what language and where and how (and which version is the recommended, when there are many competing translations), and that's really the biggest thing I'd like to solve with this.
In a multi-language environment I feel that this is almost a must-have feature in the long term... and, should it gain some momentum, I could really see that being a valuable addition to our "official site bundle" (translate.processwire.com or something along those lines), though obviously that part depends on how Ryan sees this 🙂
Anyway, just wanted to let you know that you're not along with this need. The problem for me is that I've got a pretty good idea of what I need to do, but I still need the time to do that. I hope to find just that (unless someone nails something similar down first, that is) in a few months, but that's not a certainty yet 🤞
@LostKobrakai has created a PR that even makes shipping those translations dynamic, so if one does not want to use the shipped translations one could simply not use it and stay with the current behaviour of translating everything manually.
This could also be a great feature for shipping a module with different language variants - in german we have a formal and non-formal "you", eg
Do you want some coffee?
Non-formal: Möchtest du einen Kaffee?
Formal: Möchten Sie einen Kaffee?
BernhardBaumrock
commented
3 years ago
Short description of the enhancement
ProcessWires translation system is great. But only as long as you don't want to create a module and want to ship that module with different languages. But that's a very common need, especially if you are not native english and the default language of your module is for example german.
Current vs. suggested behavior
Translations of a module should really be where they belong: Inside the module. If the module changes, the translations change as well.
Why would the enhancement be useful to users?
Imagine you created a module for SEO and you install it on every site that you create for your clients. All your clients speak german, so you translate your module to german.
One year later you have created 10 sites and you update your SEO module and of course you need to update translations for it. But it's not enough to just pull the new module version, you also need to update 10 site translations by hand.
Oh, you got 100 pages using your module? That means 100 manual translation upgrades. Lets say you change 3 strings in each 2 files, that means 2x(3+2) = 10 clicks. So for all your translations that's 100x10 unnecessary clicks. Now imagine your module is used by many people on the world... that means how many clicks? No, I don't want to imagine that :)
One could of course also copy the translation files, but I'm not sure if that would be really quicker, because the language IDs are different on every install so you'd need to be really careful what you are doing and that makes you slow again...
Demand
2013 https://processwire.com/talk/topic/2583-delivering-module-translations/
2016 https://processwire.com/talk/topic/12456-add-translation-file-to-module/
2017 https://processwire.com/talk/topic/15367-translating-module/
2020 https://processwire.com/talk/topic/23257-how-to-ship-a-module-with-translation-files/
PR
@LostKobrakai has created a PR that even makes shipping those translations dynamic, so if one does not want to use the shipped translations one could simply not use it and stay with the current behaviour of translating everything manually.
This could also be a great feature for shipping a module with different language variants - in german we have a formal and non-formal "you", eg
https://github.com/processwire/processwire/pull/52