Jump to content
bfncs

Delivering module translations

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.
  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 =)

  • Like 3

Share this post


Link to post
Share on other sites
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. 

  • Like 1

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Mike Rockett
      Jumplinks for ProcessWire
      Release: 1.5.56
      Composer: rockett/jumplinks
      Jumplinks is an enhanced version of the original ProcessRedirects by Antti Peisa.
      The Process module manages your permanent and temporary redirects (we'll call these "jumplinks" from now on, unless in reference to redirects from another module), useful for when you're migrating over to ProcessWire from another system/platform. Each jumplink supports wildcards, shortening the time needed to create them.
      Unlike similar modules for other platforms, wildcards in Jumplinks are much easier to work with, as Regular Expressions are not fully exposed. Instead, parameters wrapped in curly braces are used - these are described in the documentation.
      Under Development: 2.0, to be powered by FastRoute
      As of version 1.5.0, Jumplinks requires at least ProcessWire 2.6.1 to run.
      View on GitLab
      Download via the Modules Directory
      Read the docs
      Features
      The most prominent features include:
      Basic jumplinks (from one fixed route to another) Parameter-based wildcards with "Smart" equivalents Mapping Collections (for converting ID-based routes to their named-equivalents without the need to create multiple jumplinks) Destination Selectors (for finding and redirecting to pages containing legacy location information) Timed Activation (activate and/or deactivate jumplinks at specific times) 404-Monitor (for creating jumplinks based on 404 hits) Additionally, the following features may come in handy:
      Stale jumplink management Legacy domain support for slow migrations An importer (from CSV or ProcessRedirects) Feedback & Feature Requests
      I’d love to know what you think of this module. Please provide some feedback on the module as a whole, or even regarding smaller things that make it whole. Also, please feel free to submit feature requests and their use-cases.
      Note: Features requested so far have been added to the to-do list, and will be added to 2.0, and not the current dev/master branches.
      Open Source

      Jumplinks is an open-source project, and is free to use. In fact, Jumplinks will always be open-source, and will always remain free to use. Forever. If you would like to support the development of Jumplinks, please consider making a small donation via PayPal.
      Enjoy! :)
    • By BitPoet
      As threatened in Ryan's announcement for 3.0.139, I built a little module for sliding toggles as a replacement for checkboxes. Styling of the input is CSS3 only (with all the usual caveats about older browsers), no JS necessary, and may still be a bit "rough around the edges", so to speak, since I didn't have much time for testing on different devices or brushing things up enough so I'd feel comfortable pushing it to the module directory. But here's the link to the GitHub repo for now:
      InputfieldSlideToggle
      Fieldtype and Inputfield that implements smartphone-style toggles as replacement for checkbox inputs. The visualization is CSS-only, no additional JS necessary.
      Status
      Still very alpha, use with caution!
      Features / Field Settings
      Size
      You can render the toggles in four different sizes: small, medium, large and extra large.
      Off Color
      Currently, "unchecked" toggles can be displayed either in grey (default) or red.
      On Color
      "Checked" toggles can be rendered in one of these colors: blue (default), black, green, grey, orange or red.
      Screenshots

      Some examples with checkbox label


      View all Size and Color Combinations
      Small toggles Medium toggles Big toggles Extra big toggles  









    • By Orkun
      Hi Guys
      I needed to add extended functionalities for the InputfieldDatetime Module (module is from processwire version 2.7.3) because of a Request of Customer.
      So I duplicated the module and placed it under /site/modules/.
      I have added 3 new Settings to the InputfieldDatetime Module.
      1. Day Restriction - Restrict different days based on weekdays selection (e.g. saturday, sunday) - WORKING

       
      2. Time Slots - Define Time slots based on custom Integer Value (max is 60 for 1 hour) - WORKING

       
      3. Time Range Rules per Weekday - Define a minTime and MaxTime per Weekday (e.g. Opening Hours of a Restaurant) - NOT WORKING PROPERLY

       
      The Problem
      Time Slots and Day Restriction working fine so far. But the Time Range Rules per Weekday doesn't work right.
      What should happen is, that when you click on a date, it should update the minTime and maxTime of the Time Select.
      But the change on the select only happens if you select a date 2 times or when you select a date 1 time and then close the datepicker and reopen it again.
      The time select doesn't get change when you select a date 1 time and don't close the picker.
      Here is the whole extended InputfieldDatetime Module.
      The Files that I have changed:
      InputfieldDatetime.module InputfieldDatetime.js jquery-ui-timepicker-addon.js (https://trentrichardson.com/examples/timepicker/) - updated it to the newest version, because minTime and maxTime Option was only available in the new version  
      Thats the Part of the JS that is not working correctly:
      if(datetimerules && datetimerules.length){ options.onSelect = function(date, inst) { var day = $(this).datetimepicker("getDate").getDay(); day = day.toString(); var mintime = $(this).attr('data-weekday'+day+'-mintime'); var maxtime = $(this).attr('data-weekday'+day+'-maxtime'); console.log("weekday: "+day); console.log("minTime: "+mintime); console.log("maxTime: "+maxtime); var optionsAll = $(this).datetimepicker( "option", "all" ); optionsAll.minTime = mintime; optionsAll.maxTime = maxtime; $(this).datetimepicker('destroy'); $(this).datetimepicker(optionsAll); $(this).datetimepicker('refresh'); //$.datepicker._selectDate($(this).attr("id"),date); //$.datepicker._base_getDateDatepicker(); // var inst = $.datepicker._getInst($(this)); // $.datepicker._updateDatepicker(inst); /*$(this).datetimepicker('destroy'); InputfieldDatetimeDatepicker($(this), mintime, maxtime); $(this).datetimepicker('refresh'); */ // $(this).datetimepicker('option', {minTime: mintime, maxTime: maxtime}); } } Can you have a look and find out what the Problem is?
      InputfieldDatetime.zip
       
      Kind Regards
      Orkun
    • By teppo
      This module tracks changes, additions, removals etc. of public (as in "not under admin") pages of your site. Like it's name says, it doesn't attempt to be a version control system or anything like that - just a log of what's happened.
      At the moment it's still a work in progress and will most likely be a victim of many ruthless this-won't-work-let's-try-that-instead cycles, but I believe I've nailed basic functionality well enough to post it here.. so, once again, I'll be happy to hear any comments you folks can provide
      https://modules.processwire.com/modules/process-changelog/
      https://github.com/teppokoivula/ProcessChangelog
      How does it work?
      Exactly like it's (sort of) predecessor, Process Changelog actually consists of two modules: Process Changelog and Process Changelog Hooks. Hooks module exists only to serve main module by hooking into various functions within Pages class, collecting data of performed operations, refining it and keeping up a log of events in it's own custom database table (process_changelog.) Visible part is managed by Process Changelog, which provides users a (relatively) pretty view of the contents of said log table.
      How do you use it?
      When installed this module adds new page called Changelog under Admin > Setup which provides you with a table view of collected data and basic filtering tools See attached screenshots to get a general idea about what that page should look like after a while.
      For detailed installation instructions etc. see README.md.
       


    • By Gadgetto
      Status update links (inside this thread) for SnipWire development will be always posted here:
      2019-08-08
      2019-06-15
      2019-06-02
      2019-05-25
      If you are interested, you can test the current state of development:
      https://github.com/gadgetto/SnipWire
      Please note that the software is not yet intended for use in a production system (alpha version).
      If you like, you can also submit feature requests and suggestions for improvement. I also accept pull requests.
      ---- INITIAL POST FROM 2019-05-25 ----
      I wanted to let you know that I am currently working on a new ProcessWire module that fully integrates the Snipcart Shopping Cart System into ProcessWire. (this is a customer project, so I had to postpone the development of my other module GroupMailer).
      The new module SnipWire offers full integration of the Snipcart Shopping Cart System into ProcessWire.
      Here are some highlights:
      simple setup with (optional) pre-installed templates, product fields, sample products (quasi a complete shop system to get started immediately) store dashboard with all data from the snipcart system (no change to the snipcart dashboard itself required) Integrated REST API for controlling and querying snipcart data webhooks to trigger events from Snipcart (new order, new customer, etc.) multi currency support self-defined/configurable tax rates etc. Development is already well advanced and I plan to release the module in the next 2-3 months.
      I'm not sure yet if this will be a "Pro" module or if it will be made available for free.
      I would be grateful for suggestions and hints!
      (please have a look at the screenshots to get an idea what I'm talking about)
       




×
×
  • Create New...