Delivering module translations

[bfncs]

Hi 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?

This seems like it can't work out of the box, because everyones language subtree will be different. But since it also would be impossible to pack translations for all modules in the official repo into the language packs, is there some mechanism for this? Or maybe at least some convention how to deliver translations then? The way I understand how it works now, everyone using a module is required to translate it for him-/herself, which is a bit tedious.

With kind regards,

Marc

[Soma]

I was thinking about this alot in the past since translations are in PW. I can't remember if it was discussed already, I think only little. 

That's a valid question or concern I think we should have to recommendations for 3rd-party modules. I don't think it's tedious, just a question of how you handle it. Translations in core was added not so long a go and was a sponsored by Antii's company (?) feature Ryan added. It's s very well implemented but in some areas still a little rough (no offend Ryan). It works all well and even resulted having language text fields (adds inputfield for each language automaticly) and even possible to have alternate language fields (fieldname_de,fieldname_en) which is awesome. Creating language packs is hard work, but it's always possible to extend some things or create helpers int he future (did one recently created one here for Radek http://processwire.com/talk/topic/2540-czech-localization-textdomainhelpermodule/). Adding languages is easy but I still am not happy with the interface where the json files are stored. Hard to get an overview and deleting all is cumbersome (70+ files) manually. But the system is there and it's maybe only a matter of building a more advanced manager for the files, which shouldn't bee too difficult.

Just takes some time. We are still not even a year into PW added translation and people are now slowly coming in and start to point out issues cause they're using it. So thanks for everyone sharing he's thought to show there's some need. I know Ryan doesn't use multilanguage feature and most western don't. We in Switzerland have the opposite, 90% of the sites have at least 3-4 languages.

Mostly we do the front-end translation using yaml or php vars to have translatable strings at it doesn't have to be done with PW. Also, rarely we use modules that then would need translation for end users and most of the time the editors are one-languaged group of people. So haven't really come to using it that features much apart from the core admin.

Some things may could be considered as mandatory for modules added to repository:

• All 3rdparty module should have it's text strings translateable. (some module were built before core translation, like Thumbnails)
• All 3rdparty module should have some folder for translation to be added. So other's translating it can add the json file.

[bfncs]

Thanks for sharing your thoughts here, Soma!

I haven't been using the multi-language system heavily, just read a lot and experimented with it, and I think all in all it's already a great solution, especially while it is still so young! The "tedious" was more targeted to the fact, that probably a lot of translations for modules are done over and over again, because currently there's no good way to share them with each other.

I think the approach you took with the JSON files is something very usable, but I also agree, that it will need a more comfortable manager at some point - while this might prove to be sufficient for most needs.

For me the most crucial point currently is to deliver a backend with one consistent language throughout the UI the editor sees, which means that I'll have to translate some modules here and there. I also read a lot about multilanguage in the frontend and the route you propose with YAML/PHP-vars sound really reasonable to me for small to medium-sized sites.

So, in the end the two points at the end of your post is ultimately what I want to completely agree on.

[apeisa]

Delivering language packs through module download is one way to go. Other one is having github repo per language.

Also when this will be decided, there should be possibility to mention translations (with credits for translators) in modules.processwire.com listing.

[bfncs]

I think I'd prefer to get the translations with the module. This will make it more easy to find the right place to contribute your translation to. Also, in the module management, there might be a function added at some point to look for translations inside the module directory and add them to a language you specify.

What is definitely needed then is a convention for this.

[Soma]

Translation for core admin, we already have repos.

To pack all 3rd party module translation into them too I think is not a good idea at all. Better keep them with the module they belong to.

[apeisa]

What I meant was repo for each language per module (just like there is multiple repos for core translations). Languages comes from different authors than the actual module.

not sure though, might be easier to have i18n folder within module repo.

[bfncs]

So for each module for each language another repository? Or one repository with all translations for one module, but separate from the module itself?

[apeisa]

First one.

[bfncs]

Hm, this seems like a clean solution, because everyone can only watch the translations he's interested in and so on. On the other hand, if you have quite a lot of translations, the overhead for managing all the repos might be quite big.

I'm not so sure, what will be the best way to do this to be honest.

[bfncs]

This thread has gotten quiet old but I still think there has been no approach to solve the problem until now. Any news on this one?

[owzim]

I think there should be only one repo per language containing all module translations. 

One repo per language per module is overkill I think, because most of the modules need only one language file, right?

Just for the sake of an comprehensive view in the repo, each Module should have its own folder.

The repo then can be managed by someone who speaks that language and can take pull requests from other contributors. I think this central way is more approachable for those who want to help. 

What could be problematic is that the language files are created in only one line, compressed, which makes it hard to track line by line changes in a repo.

I am willing to open such a repo for German if no one else wants to =)

[ryan]

What could be problematic is that the language files are created in only one line, compressed, which makes it hard to track line by line changes in a repo.

They shouldn't be compressed. Regarding the 1-line issue, we can correct this on PHP 5.4 and newer as json_encode() now has a JSON_PRETTY_PRINT option, which makes it output the JSON in a human readable way (and I'm assuming a much easier-to-version way). I'm going to add a check for PHP 5.4 so that we can start taking advantage of this now. 

[Radek]

One git repo per language containing all module translations seems like reasonable way to do it.

Currently i am publishing Localization Pack for external modules like zip file with simple directory structure for each module.

[Manfred62]

are there any news about 'module translations'?

Should we collect module-translations generally under the main language, or better place them under the related module?

Or simply post them in the forum (in the relevant language thread) as downloadable files?

[apeisa]

I think best would be single repo per language and each module as a subdir.

[yellowled]

I was also wondering how other language pack maintainers handle multiple versions corresponding to different PW versions. Manfred tells me he's got lots of 2.4 already translated (which is great, thanks!), but because of changes between 2.3 and 2.4, both language pack version differ greatly.

I could imagine using GitHub tags or branches for versioning to keep seperate versions for 2.3 and 2.4 available (tags would probably be nicer since GitHub generates the Releases page from those automagically), but I'm not sure if it's actually necessary. Also, the Modules Manager handles language packs as well, which I find very convenient, but I'm not sure if it could handle versioned language packs? Maybe Soma could chime in on this.

I guess what I'm ultimately wondering is: if the language pack repo contains the latest dev version already, can 2.3 still use these language files? Or should we just wait with the translations until 2.4 is actually released?

[Manfred62]

but because of changes between 2.3 and 2.4, both language pack version differ greatly.

the main difference is the new 'admin theme as module' concept. Now the paths have changed. See this post. Ryan already replied, he will change the admin-translation-system to be easier. Maybe something like a new class, where all admin-themes will point to the same file.

Example idea (something like this):

/wire/modules/AdminTheme/admin-lang-default.php

So we will be able to put all admin-theme-translation in one file (for all themes).

Module translation: I think most module translations are independent from this admin topic, because modules are placed in own directories anyway. So best will be, to set up subdirectories in the language repo.

I guess what I'm ultimately wondering is: if the language pack repo contains the latest dev version already, can 2.3 still use these language files? Or should we just wait with the translations until 2.4 is actually released?

I'm also curious...

[Soma]

Modules Manager can't handle LanguagePacks, it just lists them but you can't install them.

Maybe in future we could support that too. But I'm fearing too much work would be put into for something that may change to the better at some point.

I'm also not very satisfied with current system of translation and versions etc of modules. I think there would be much better ways to manage, install, update etc with a  more sophisticated system some sort of. Remember Modules Manager is still "alpha" proof of concept type module, doing the work for you downloading and putting manually things in place.

[bernhard]

I've created an issue in the requests repo - please give it a thumb up to show demand for such a feature!

https://github.com/processwire/processwire-requests/issues/396