Jump to content

Search the Community

Showing results for tags 'translation'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Welcome to ProcessWire
    • News & Announcements
    • Showcase
    • Wishlist & Roadmap
  • Community Support
    • Getting Started
    • Tutorials
    • FAQs
    • General Support
    • API & Templates
    • Modules/Plugins
    • Themes and Profiles
    • Multi-Language Support
    • Security
    • Jobs
  • Off Topic
    • Pub
    • Dev Talk

Product Groups

  • Form Builder
  • ProFields
  • ProCache
  • ProMailer
  • Login Register Pro
  • ProDrafts
  • ListerPro
  • ProDevTools
  • Likes
  • Custom Development


There are no results to display.

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 29 results

  1. This is my first post so, Hello everyone. Ryan, I want to congratulate a great CMS. I attach my translation for the Polish language. The translation is fairly complete, but it requires some adjustments. Hidden deeper setting are not yet translated. And also the Polish translation for TinyMCE. TinyMCE will not work without it. https://github.com/PawelGIX/ProcessWire-Language-Pack-Polish--pl-PL- EDIT: I added a link to github. ProcessWire-Language-Polish.zip tinymce_language_Polish.zip
  2. "Deepl" is an unbelievably good (paid) text translation service, that mops the floor with Google Translate. They have an API and it would be awesome, if there would be a module, that would integrate it for easy content translation. It could be a right-click context menu on the language tab: It should ask from which of available other language it shall take translate from. What do you think?
  3. Hi guys, I need help. how do I translate Next Page? <?php if($page->next->id) {echo "<div class='float-right'><a class='button' href='{$page->next->url}'> Next Page </a></div>";} ?> I usually use this: <?php $lang = $user->language->name; if($lang == 'default') {echo "Next Page";} else {echo "Pagina successiva";} ?> or <?php echo __("Next Page"); ?> Thanks
  4. Does anyone here have experience installing a translation module that creates new pages for multiple languages? I am assuming when these pages are generated, they are indexable by google as "new" and "fresh." Thoughts?
  5. I am using the translation function (either $this->_() or __()) within a module that responds to AJAX API calls - there isn't really a page that is being served. When I supply a string with an apostrophe, e.g., __('Book \'em danno') It is formatted as Book &#039;em danno Is there some way to prevent output formatting when retrieving strings using the translation functions?
  6. There's a permission for allowing editor to use the translator in PW 2.73. I could need this but it doesn't work. It shows the "Language" in the menu but when opening the page it says no entries to show. Anybody has some experience using the lang-edit permission for editor?
  7. Hello, In this tutorial I show how to use the wirePopulateStringTags function in order to improve translatable strings. https://medium.com/@clsource/better-translatable-strings-in-processwire-621e9e6b18ee#.tv2u23j4i Basically it will improve how the strings are shown in the translation administration. echo wirePopulateStringTags( __('There are {count} {items} in the {place}'), ['items' => 'apples', 'count' => 32, 'place' => 'basket'] ); Will render There are 32 apples in the basket And the Translator will see There are {count} {items} in the {place}
  8. I do love PW for a lot of reasons, but the language translation tool is not that easy to deal with. The site I am working on is in French and there will be no translation, so the default language has been translated into French (importing the french language pack, which is not up to date, and completing lot of stuff). However, for a reason I don't know, some buttons stay in English. I was able to find the string pattern %s + Next, and tried numerous variation. Everything is translated except Save + Next! As we say in French, PW a des croutes à manger à ce niveau. (probably not really translatable... ;-) PW has some crumbs to eat on that level). While there was a great improvement on language translation management, wouldn't it be easier to have a tabled list of all translations? And, why, for example, should we have to enter the translation for "Save" at every occurrence in modules? ListerPro (which we purchased for that site) is really great to make searches. Would be fun to have translations strings placed in the admin area as pages... Food for stuff? Any way, back to my chase of %s + Next... (or whatever I will discover)
  9. By Processwire default the Installation is always in English. As Ryan said earlier: To install a new language pack withNicos Module is easy buthow to get it running as Default. And where actually do you get the default ENGLISH files as if you exchange the default files English will be gine. It is even one when you change the name and title to something else than default. IMHO there need to be a way to switch to a default language with / much easier. All the tutorials - which are great - unfortunately keep the default Lingua Franca = English. i.e. can somebody perhaps point to a tutorial how to setup German, or any other language than English as Default Language and how to get as second Language English running without having to disable the default Language field or moving files from German to be default? This is absolutly not developer Friendly as it costs a lot of time and bears the danger that things get lost or modified at the wrong place. IMHO Nicos approach with uploading the translations in a one tep process is a good way but as said the English translation is missing! Also it does not seem to be possible to upload a language file again i.e. for updating as translations usually change with every version. It would be great if this Tutorial here http://processwire.com/api/multi-language-support/ would point out into the right direction if you are not inteded to use English as default language but still need English as another Language. Thanks
  10. Hello everyone. I have strange things happening when I want to edit Site translation files. When I try to edit files I got error: " Session: File does not exist: /site\templates\include\footer.inc (translation file not needed? textdomain: site--templates--include--footer-inc) " Here I noticed strange division on left. Somehow it is change direction. Can anyone explain to me why this is happening, and can cause this error?
  11. I'd like to change the error message "missing required field" update-safe. According to the config file documentation, I can do that as follows: // file site/config.php $config->InputfieldWrapper = array( 'useDependencies' => true, 'requiredLabel' => 'Valeur requise manquante', ); But this does not work. The only thing that seems to work is to change the error message directly in the file InputfieldWrapper.php Christophe is also talking about this misbehaviour. Is this a bug? Or did I miss something?
  12. Hello, I face interesting issue in PW v3. I have utility class, which is loaded from template. Class is put in namespace due to some naming collisions. But it is impossible now to use translatable strings in it. <?php namespace site\util; class Utils { public function func() { __('car'); // Error - function site\util\__ does not exist. $this->__('car'); // Error - method Utils::__ does not exist. \ProcessWire\__('car'); // Code runs, but PW does not recognize translatable string in admin area. } } I guess that this will not be issue in PHP 5.6 anymore, because you can use... use function ProcessWire\__; But how to deal with it in PHP 5.5? May be I could extend class Utils from some PW class to make $this->__() accessible? I mean... class Utils extends ProcessWire\ClassWithTranslationMethod { public function func() { $this->__('car'); } } Or do you see other solution? Thank you for all your ideas. Martin
  13. Hi all, We have this huge website (over 7000 pages and a few dozen templates). We've used TextLanguage and TextAreaLanguage fields for all textual fields, and all image and file fields have their own description input boxes for different languages too. Now we'd need to export all pages and send them to our translator so they can translate all site contents with their specialized programs, and a way to import the translations back to our site alongside the content in original language. Has anyone done anything similar to this? How did you solve it? Maybe there already is a solid way to do this, or an idea we've not thought of yet. Thanks for any thoughts!
  14. Hello guys, 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? Or do I always have to import these language files manually? Great would be: My finished module auto-imports a translations.json file in the module's directory on initial install. Maybe some standards like https://en.wikipedia.org/wiki/ISO_639-1 so ProcessWire can iterate through the translations.json and checks if each language is installed. If so, then PW automatically imports the needed json language data for this specific language. Thanks for your answers! Steve
  15. Here's my very first and not polished version of ru-RU translation. So, now you can enjoy all this cyrillic madness Ryan, I have a question. Is it possible to store cyrillic symbols without this transformstion to Unicode (?), so the json files are editable in any editor? It's not too much needed though. Update: I've just created a GitHub repo ProcessWire Russian Language Pack ru-RU where you can find the latest Russian language pack for PW's backend. Also attached a new version of the pack, but in future I won't be updating it here, so please download it from GitHub. slkwrm-ProcessWire-Russian-Language-Pack-ru-RU.zip
  16. Ryan, Is this list of translatable files still up-to-date? By the way, /wire/modules/LanguageSupport/ProcessLanguageTranslator.module doesn't seem to have translatable phrases. //Jasper
  17. Does anyone happen to have a language pack for Danish? I don't see one in the Language Packs forum or the corresponding area in the docs/modules portion of this site. Sorry if I just missed it. Thanks, Jason
  18. I have set the right Datepicker translation file "/wire/modules/Jquery/JqueryUI/i18n/jquery.ui.datepicker-de.js". And change the code from: /* German initialisation for the jQuery UI date picker plugin. */ /* Written by Milian Wolff (mail@milianw.de). */ jQuery(function($){ $.datepicker.regional['de'] = { closeText: 'schließen', prevText: '<zurück', nextText: 'Vor>', currentText: 'heute', monthNames: ['Januar','Februar','März','April','Mai','Juni', 'Juli','August','September','Oktober','November','Dezember'], monthNamesShort: ['Jan','Feb','Mär','Apr','Mai','Jun', 'Jul','Aug','Sep','Okt','Nov','Dez'], dayNames: ['Sonntag','Montag','Dienstag','Mittwoch','Donnerstag','Freitag','Samstag'], dayNamesShort: ['So','Mo','Di','Mi','Do','Fr','Sa'], dayNamesMin: ['So','Mo','Di','Mi','Do','Fr','Sa'], weekHeader: 'KW', dateFormat: 'dd.mm.yy', firstDay: 1, isRTL: false, showMonthAfterYear: false, yearSuffix: ''}; $.datepicker.setDefaults($.datepicker.regional['de']); }); to: /* German initialisation for the jQuery UI date picker plugin. */ /* Written by Milian Wolff (mail@milianw.de). */ jQuery(function($){ $.datepicker.regional['de'] = { closeText: 'schließen', prevText: '<zurück', nextText: 'Vor>', currentText: 'heute', monthNames: ['Januar','Februar','März','April','Mai','Juni', 'Juli','August','September','Oktober','November','Dezember'], monthNamesShort: ['Jan','Feb','Mär','Apr','Mai','Jun', 'Jul','Aug','Sep','Okt','Nov','Dez'], dayNames: ['Sonntag','Montag','Dienstag','Mittwoch','Donnerstag','Freitag','Samstag'], dayNamesShort: ['So','Mo','Di','Mi','Do','Fr','Sa'], dayNamesMin: ['So','Mo','Di','Mi','Do','Fr','Sa'], weekHeader: 'KW', dateFormat: 'dd.mm.yy', firstDay: 1, isRTL: false, showMonthAfterYear: false, yearSuffix: ''}; $.datepicker.setDefaults($.datepicker.regional['de']); $.timepicker.regional['de'] = { timeText: 'Uhrzeit', hourText: 'Stunde', minuteText: 'Minute', secondText: 'Sekunde', millisecText: 'Millisekunde', timezoneText: 'Zeitzone', currentText: 'jetzt', closeText: 'schliessen', }; $.timepicker.setDefaults($.timepicker.regional['de']); }); But it only affects the date and not the time. What I'm missing?
  19. I was looking through the site show case forum and there are a lot of awesome sites. The most common down fall is the context/language. I think it would be a huge improvement to improve the language support in the core.
  20. We're working on a site that has translations set. (two languages). Suddenly, one of the template doesn't show the correct language. I tried to load the translated strings (the page in question appears as it should on the translated files), i get the error that Processwire cannot load it. Any idea on how to fix this? I'm using 2.5.3.
  21. Heya, everybody! The Hungarian language pack for Processwire is on the way. I will post here about the stages of the translation process. Stay tuned!
  22. This Thread is opened new as it will only discuss a centralized solution! nothing more and nothing less! The quotes are coming from the former Thread which was actualy about finding Language files on Mac and had nothing to do with the actual problem of PW! In Processwire there are 2 major problems with translations when working especially with Multidomain sites in one processwire DB 1. The default can not be defined on a per site base like in other CMS with Multidomain support in one DB. i.e. the default language get's defined by the guest user but this guest user is existing only once! You can't define a guest user on a per Domain Base in a multidomain installation which is working with one DB. Solution: Instead of defining the default language by the language of the guest user it woudl be advised to have some code or dropdown or whatshowever to choose the right default language on a per site base. This can happen i.e. through code inserted in a specific site template belonging to one domain. 2. Working with translations in Processwire is a hazzle - really and it could be much much easier. We are just testing it if Weblate or Pootle could do the job and the same with the documentation to probably use readthedocs / sphinx instead. To reduce workload on the developer site and also to increase the quality of documentation and translations it is very important to be able to collaborate with others on this. Therefor a local solution (in a module or elsewhere locally) can never be the right way in terms of smoothness, economie and workflow. As we need at least 2 - 3 translations in nearly every site we are working with including the translation of documentation (especially those for editors and site admins) we will work on a solution which lateron might help to solve the problems of all. I only hope that the modules don't get cluttered up with lots of localized files now. - If this would habben than each module we are using here will have soon also translations of Thai, Khmer, Laos, Burmese, etc in it and for sure nobody in Europe would need them! Keeping things centralized on a centralized system is the much much better way for translations and documentations. This is the case if you need to run all churches from their own DB as some have german, some English, some Thai, some even Arabic as default language! And for sure we won't handle such an amount maintaining all those translations - that's why the churches would need to handle their stuff all by them selves which will end up in a chaos and finally in a no go command from those churches to use Processwire! Most of those Churches work with volunteers and are not those Mega Million Churches with Cathedrales etc. like you see often in the US. They have usually a dedicated webteam, but ours are very tiny units and need to keep costs at anabsolut minimum. The same applies to the multidomain School Servers with many school/classroom websites in them etc. 90% of them would need another default language than English and the default languages are changing depending on the location where they are. Well as pointed out above it will be a real hazzle to keep the quality of translations and the standards if there is no centralized solution in doing all the translating stuff. Updating a translation can happen by a module and should happen by a module - no question! - But instead of storing all translations inside a module it would be adviced to keep them separated and store only one language (the default language of the module - which could also be German or even Thai) inside the module. The module in the backend would than check with the translation server which new translations would be available and download those tranalations ONLY for those modules you have installed. Those translations than get storred in a separate directory where wll those translations can be managed or even be overwritten partly by a second local translation folder for only local translations. With a fall back methode it gets checked which translation is available and should be used. is the translation available in the folder for local translation yes no? If no than check in the global translation folder yes no? If no download it from the language server? yes always means = use it. And the update process would be similar but simply skipping the local translation folder. This way you can ensure that modules always have accurate and updated translations. Finally you might run that process than via a cronjob or manually - up to you! --- Translations itself will be done on Weblate or Pootle and docs (so our idea on readthedocs or a global sphinx) Module editor provides the default language (which could be any - but the language would be needed to be specified by a code - i.e. en_UK, de_CH, de_DE etc. A parser will parse the modules directory for those default language file and convert the json into mo/po for use in Pootle. With Weblate we could integrate json directly On Weblate/Pootle those files can be translated in a collaborative effort, even by none developers, but i.e. by people who are good in translating stuff - this keeps the quality high and it will reduce the workload on developer sites as they don't need to worry about the translations or even don't have to integrate them into their modules etc. Now an integrator sets up a website and defines the default and other languages. A module will now check if there are new translations available for the installed languages and they can be downloaded and stored in the site like described already above. -- Maintenance Tasks would be quite low on the site of the Weblate/Pootle Server site. The benefit of Weblate would be that they have a FREE hosted Version of webslate of OpenSource Projects - so no maintenance stuff would on PW site concerning the translation server which is great. (but we would need to change some stuff - see below) Readthedocs is very well maintained already and it is completely free! An ideal way to do documentations and meanwhile used by lots of projects and parts of projects. And of course the module which will manage the translations needs to be maintained to so that it will continue working when the core gets updated. But this would be the case anyway with any module ;-). But here we would need to manage the connection to weblate/pootle. But also here the hosted webslate solution would be the best way to go as it can parse github repos and the translations of readthedocs will be actually hosted on a github ;-) In other words it will simply work. using Pootle it woudl be a little bit more work as the Pootle server would need to be maintained as pointed out already. -- Extendibility of that idea: 1. Integrating a backend part to translate / propose translations from within PW 2. Doing the translation of strings with a local application (which than will store those localized translations in the folder for local translations, like described above.) This can already be done by a module and this module only would need to be adjusted (enhanced) to work with translatins coming from the central langauge repository. -- WEBLATE - READTHEDOCS - GITHUB We discussed it here in our Team and we think that it is the best way to go! If there are any other ideas let us know - but for sure we are not interested in a solution which will clutter up module and corefiles with all kind of translations/documentations which we won't use on our sites! And it must be a solution which allows collaboration with others to reduce workload. Readthedocs can work with transiflex but until now we can't see a better free solution than weblate or pootle http://www.oneskyapp.com/comparison/transifex-alternative/ Some links for those interested: Readthedocs (maintained and hosted) https://readthedocs.org/ Weblate (maintained and hosted) http://weblate.org https://hosted.weblate.org/ http://weblate.org/en/features/ http://weblate.org/en/hosting/ Pootle (selfhosted) http://pootle.translatehouse.org/ We propose the following way to go IMHO https://hosted.weblate.org/ + https://readthedocs.org/ + https://github.com/ Benefits: We could reuse the JSON Collaboration on translations would be available Documentation would be available for translation to The code gets already maintained on github while I suggest to open up another repo in which all modules (also those not approved meanwhile by the ryan team) could be integrated for translation and documentation. This would help to get translations and documentations done already in an earlier state than stable. If you know a better maintained and free solution like we proposed above to be used for a collaboartive translation and documentation effort, please point it out and describe the benefits of it in comparison to what we propose here. --- Important REMARK: This thread is NOT meant to discuss if there should be a centralized or only a local solution! Please keep all stuff concerning this out of that Thread and discuss it elsewhere. This Thread here is ONLY! about a globalized collaborative solution where the translations get managed at a centralized place and where documentation gets written on a centraliced place and where we create a module to integrate all those translations and documentations. Who would be interested to work with us on getting things done and to move the modules and documentation to weblate and readthedocs. PM us! Thanks.
  23. Hello guys, hope you all have a great day. so I want to translate my templates element based on selected languages i.e "read more" button, "follow me" button, etc. in wordpress we can do something like this <?php _e( 'Some text to translate and display.', 'textdomain' ); ?> and then translate it via .mo files, how to achieve similar to this using PW or is there better way doing this?
  24. The great latest localization enhancements for PW 2.5 raise some problems due to the multi-language site profile. I observed that when the site translation files are included in the core translation files language pack, they are unnecessarily uploaded to the Core Translation Files and I can delete them, but cannot move them to their appropriate location. As the translation files are distributed in one package, many of them downloaded directly from GitHub, it would be a smarter solution if the language pack uploader dispatched the site language files to the Site Translation Files section. It turned out in Ryan's answer on my GitHub issue report, that we cannot use these site translation files for monolingual sites, so it would be recommended if the language pack uploader detected the multilingual status and when it failed (due to monolingual site), it displayed a warning and did not upload the site language files.
  25. Krase

    Website localization

    Guys, this aspect has tormented me in the past couple of weeks and I just want to hear more opinions. What is your approach towards translating websites, themes or apps? I have recently discovered this tool: https://poeditor.com which sort of seems to me more human than the other mainstream crowd translation tools and I've been using its API and exploring its functions. I;m sure that translators really feel at home when working in a helpful interface. However, I still find proofreading a problem... What do you think?
  • Create New...