Jump to content


  • Posts

  • Joined

  • Last visited

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Düsseldorf, Germany

Recent Profile Visitors

2,404 profile views

robert's Achievements

Jr. Member

Jr. Member (3/6)



  1. Translating only changed fields is quite a good idea, I just added it in v0.7 😄 New radio option: Write Mode (replaces the checkbox Overwrite Existing Translation) Translate only if target field is empty Translate only changed fields Overwrite all target fields Caution: the »Changed fields«-option support is currently only one level deep. If you change any value inside a Repeater(-Matrix) or FieldsetPage field, the complete field will be translated. If anybody knows how to get the names of nested fields that changed inside the afterPages::saved hook, please let me know 🤔
  2. @bernhardSure 🙂 Module Config (sorry for the mixed labeling, I have the german language pack installed 😅 ): Publish + Translate to all target languages at once: Publish + Translate to single languages (on the left side of the arrow: source language, right: all available (aka not excluded) target languages):
  3. v0.6 is released with the following changes: New setting: Source language (thx for the idea to @Ivan Gretsky and for the pull request to @theoretic) Languages for source and exclude can only be selected if they have been defined in the fluency config first I had to do some refactoring of the translation strings and the module config, so please validate/correct your settings after the update to v0.6!
  4. @studioweb I had a deeper look into the page->name feature request and decided to not include the automatic translation of this field. As I suspected in my last post, there exists already a better solution for this 😅 If you install the module https://processwire.com/modules/process-setup-page-name/ and activate its option ›Update the name of existing pages‹, the name field will be updated in all languages whenever you change the corresponding field (normally title).
  5. @studiowebThanks 🙂 To prevent possible misunderstandings: you’re talking about the $page->name field, right? This is indeed a special case as it is the only translatable system field I could think of. I would suggest the following mechanism: only translate the page name if the target language name is identical to the source language (and therefore: not translated yet) – and allow users to switch it off in the settings to prevent possible conflicts with other modules modifying the name field on save (e.g. ProcessSetupPageName).
  6. Oh cool, sounds good 🙂 Your addition might be a good fit for the open issue by Ivan Gretsky: https://github.com/robertweiss/ProcessTranslatePage/issues/3 – would it be an option for you to fork my repository on Github so we can merge via a pull request?
  7. Just released v0.5 which includes the following new features: Exclude fields: choose fields which should not be translated Exclude languages: choose languages which should not be translated to Show Single Target Language Buttons: Show all target languages as single buttons in the save dropdown instead of having only one button for all translations Thanks to @Ivan Gretsky for proposing these additions!
  8. Hi Roych, thanks for your feedback! I found the bug – I falsely assumed that the default language id in processwire is always 1022 (which is obviously not the case …). I pushed a bugfix to the github repo (https://github.com/robertweiss/ProcessTranslatePage) and changed the version to 0.0.3. Could you try the bugfix and see if it works for you now?
  9. I created a companion module for Fluency to translate all fields on a page at once: https://github.com/robertweiss/ProcessTranslatePage You can find the corresponding conversation about it in the Fluency thread (link below), but I decided to add the module to the official list so others who have a need for this have an easier time finding it.
  10. Thank you, this would not be possible without your excellent module! I just pushed a new version to Github. The module got some additional features: A config page where you can exclude templates and toggle whether you want to overwrite already existing translations The language selection now uses the settings made in the Fluency config instead of having to configure it twice 😅 Support for more than one target language (I never needed that but thought it would be nice to have in the future) Support for the ProField Table About the performance: I share your concerns, but my client still forced me to do it 😄 The largest page I tested had 63 fields (25 textfields, 14 file-descriptions, 24 richtext-fields) and took about a minute to translate, so you really have to take care of the php timeout-settings. To bypass that, I added a small external translate-pagetree script to the repository which can be used in the command line, so you can batch-translate multiple parts of the website (or all of it) at once. As this is not tested very well, a database-backup is recommended before trying!
  11. I’m not quite sure if this is of interest for anyone and if this is the right forum for my post, but I got the client request to build a module extension for Fluency which translates all the text fields in a page with only one click. The module is not really ready for public (or the modules section), as it has no config page yet and was only tested in one ProcessWire installation, but maybe it is useful as a starting point for anyone who is in the same situation as me: https://github.com/robertweiss/ProcessTranslatePage The module checks for fluency-translate permissions and adds a ›Translate and save‹-button to the edit-page. It supports all core language fields, Repeater, FieldsetPage the pro modules Repeater Matrix, Combo and Functional Fields. Caution: for now, the (language-)settings have to be manually edited in the hookPageSave-Method (Lines 64–69).
  12. Hi @adrian, I changed the autoload to true according to your suggestion, so the properties will be added to the $page in the admin as well. Now I get the following error message from Tracy Debugger every time I open an admin page (no error shows up in the frontend): The weirdest thing is: when I duplicate my module and change the classname to something else (TestModule or similar), uninstall the original module and install the copy instead, the error is gone. And when if I remove all the code from the original class except the getModuleInfo method, the error is still there. I checked the behaviour in two other installations, they show the same error. Maybe this is some sort of race condition with autoload modules? I tried to understand the OutputDebugger class mentioned in the error, but did not yet figure out what it does or how it can help 🤔 This issue has no priority at all, but maybe you have an idea where I could look further. Debugging the debugger … 😄
  13. Hi @adrian, first of all thanks a lot for your fast and nice reply, this community is always so helpful and motivating! 1) Good idea, I never really used it that way, but I definitely will check it out and change the autoload setting. 2 & 3) Thanks for the hints, I changed the code as you suggested. 4) You are right – in combination with Tracy and usual field configurations, the difference is mostly a formatting preference. As I like using Ray in an external window for debugging, the module helped me to always get identical informations in different environments. Another thing which was important to me is the support for ›subfields‹, so that I can immediately see the content of repeater matrix items inside repeaters inside fieldset page fields etc. etc. (you see the point … 😇). The third thing is – as you already mentioned – the support for all kinds of fieldtypes in a more or less consistent and simplified way.
  14. I often had the need for an overview of all used fields and their contents for a specific page/template while developing new websites without switching to the backend, so I made a small module which lists all the needed information in a readable manner (at least for me): Debug Page Fields https://github.com/robertweiss/ProcessDebugPageFields It adds two new properties to all pages: $page->debugFieldValues – returns an object with all (sub-)fields, their labels, fieldtypes and values $page->debugFieldTypes – returns an object with all fieldtypes and their corresponding fields // List all values of a pages $page->debugFieldValues // List a specific field $page->debugFieldValues->fieldname // List all used fieldtypes of a page $page->debugFieldTypes I recommend using it in combination with Tracy Debugger, Ray, Xdebug etc. as it returns an object and is only meant for developing/debugging uses. For now, the fieldtype support includes mostly fieldtypes I use in my projects, but can easily be extended by adding a new FieldtypeFIELDNAME method to the module. I use it with five different client installations (all PW 3.0.*), but of course there might be some (or more) field configurations which are not covered correctly yet. Supported fieldtypes Button Checkbox Color Combo Datetime Email FieldsetPage * File FontIconPicker Functional Image ImageReference MapMarker Multiplier Mystique Options Page PageIDs PageTitle Radio Repeater * RepeaterMatrix * RockAwesome SeoMaestro Table Text Textarea Textareas Toggle URL * The fields with complete subfield-support also list their corresponding subfields. Installation Download the zip file at Github or clone the repo into your site/modules directory. If you downloaded the zip file, extract it in your sites/modules directory. In your admin, go to Modules > Refresh, then Modules > New, then click on the Install button for this module. As this is my first ›public‹ module, I hope I did not miss any important things to mention here.
  15. Hi Adrian, you are absolutely right! As soon as I switch output formatting off, the results are identically. Thanks for the fast clarification 🙂
  • Create New...