Jump to content
bernhard

How to ship a module with translation files?

Recommended Posts

I wonder what is currently the best way to ship a module that defaults to english let's say with german translations? I think the translation files have to be uploaded to the relevant language page (eg german) and are then stored in /site/asstes/files/my-german-page-id/... 

What if I want to ship a module with translation files included? That's currently not possible, is it? I wonder if the PW core should be modified to not only look for translations in /site/assets/files/german-id/my-module-transation-file.json but also in /site/modules/my-module/translations/german/my-module.module.php.json

What do you think? Am I missing anything?

  • Like 1

Share this post


Link to post
Share on other sites

Apparently, that's an old question:

https://processwire.com/talk/topic/15367-translating-module/

https://processwire.com/talk/topic/2583-delivering-module-translations/

Seems like nothing has changed in that regard in the last years 😞

I'm sure there would be workarounds, but then every module developer would have to create such a "install multi-language files" routine for himself, and that's hardly efficient (e.g. a menu in your module config screen where you could map JSON file A to PW-language C, and then the file(s) would be moved to the right folder. It would indeed be nice to have that functionality in the core.

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)

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...

On a side-note: Ryan is maybe missing out on marketing arguments here... it would be easy for him to aggregate at least a dozen translations for his modules from existing developers / agencies who bought a license and translated everything on their own. In return, he could give away licenses or free access to the VIP support boards to those ppl who translate Pro module JSON files ( A classical win-win situation 🙂).
For some ppl, it makes a difference if a module is already translated in x languages or just English. That's a robust sales argument right there.

Edited by dragan
added side-note
  • Like 4

Share this post


Link to post
Share on other sites

Thx @dragan

that are really some old threads! 😮 That doesn't make me feel very confident that such a feature finds its way into the core soon. I could also think of a module that copies over translation files from modules folders to the assets folder of the language.

The translation module could also lock the translation screen of the json file to prevent unwanted overwrites (or show a warning). And the module could make the necessary links between the sites language names and the standardized translation directories in the module, eg a site having language "german" could link to the module's translation folder DE. On another site the superuser could make the link deutsch-->DE instead of german-->DE

We could also ship some common translations directly in that module (eg for ListerPro)...

  • Like 1

Share this post


Link to post
Share on other sites

On a related note: Does anybody know what these random strings like 6450242531912981c3683cae88a32a66 are used for?

{
    "file": "site\/modules\/FormBuilder\/ProcessFormBuilder.module",
    "textdomain": "site--modules--formbuilder--processformbuilder-module",
    "translations": {
        "6450242531912981c3683cae88a32a66": {
            "text": "Formulare"
        },
        "c9cc8cce247e49bae79f15173ce97354": {
            "text": "Speichern"
        },

(This short excerpt is from a generated translation file for Form Builder)

Is this just for making sure you get a valid JSON and keeping key/values intact when you switch between PHP arrays and JSON? (keys)

Share this post


Link to post
Share on other sites

I guess that's a unique hash that represents the translated string (including options)

Share this post


Link to post
Share on other sites
1 hour ago, bernhard said:

That doesn't make me feel very confident that such a feature finds its way into the core soon.

That's why I shared my idea about a module that handles this... @LostKobrakai has even submitted a PR and nothing happened. I don't see any real drawbacks of packing such a feature into a 3rd party module. If one wants to ship a module with translations everybody can do so. If not - no harm, as everybody can still translate everything like before.

Having translation files in the modules folder does not only have the benefit that others don't need to translate the module (or copy over files) it does also make it easy to handle translations in a proper place for the module author and make changes to the translation across multiple installations instantly and easily (git push).

Share this post


Link to post
Share on other sites
14 hours ago, bernhard said:

I could also think of a module that copies over translation files from modules folders to the assets folder of the language.

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 🤞

 

  • Like 3

Share this post


Link to post
Share on other sites

Hi @teppo

yeah, that would be awesome! Carbon has a great translation tool: https://carbon.nesbot.com/contribute/translate/

I've recently suggested an improvement for de_AT and it's already in the package, available for everybody. I just opened a new ticket right now - see here how this looks like: https://github.com/briannesbitt/Carbon/issues/2036

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...