Jump to content

Search the Community

Showing results for tags 'translation'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • 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

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

  1. Hello community! I want to share a new module I've been working on that I think could be a big boost for multi-language ProcessWire sites. Some background, I was looking for a way for our company website to be efficiently translated as working with human translators was pretty laborious and a lack of updating content created a divergence between languages. I, and several other devs here, have talked about translation integrations and have recognized the power that DeepL has. DeepL is an AI deep learning powered service that delivers translation quality beyond any automated service available. After access to the API was opened up to the US, I built Fluency, a DeepL translation integration for ProcessWire. Fluency brings automated translation to every multi-language field in the admin, and also provides a translation tool allowing the user to translate their text to any language without it being inside a template's field. With Fluency you can: Translate any plain textarea or text input Translate any CKEditor content (yes, with markup) Translate page names for fully localized URLs on every page Translate your in-template translation function wrapped strings Translate modules Fluency is free, and now so is DeepL Since this module was first built DeepL has introduced free Developer accounts that allow anyone to start using Fluency at zero cost and beginning with the version 0.3.0 release Fluency now supports free DeepL accounts. As of June 2021 DeepL supports translation to 26 languages and continues to offer more! Installation and usage is completely plug and play. Whether you're building a new multi-language site, need to update a site to multi-language, or simply want to stop manually translating a site and make any language a one-click deal, it could not be easier to do it. Fluency works by having you match the languages configured in ProcessWIre to DeepL's. You can have your site translating to any or all of the languages DeepL translates to in minutes (quite literally). Let's break out the screenshots... When the default language tab is shown, a message is displayed to let users know that translation is available. Clicking on each tab shows a link that says "Translate from English". Clicking it shows an animated overlay with the word "Translating..." cycling through each language and a light gradient shift. Have a CKEditor field? All good. Fluency will translated it and use DeepL's ability to translate text within HTML tags. CKEditor fields can be translated as easily and accurately as text/textarea fields. Repeaters and AJAX created fields also have translation enabled thanks to a JavaScript MutationObserver that searches for multi-language fields and adds translation as they're inserted into the DOM. If there's a multi-language field on the page, it will have translation added. Same goes for image description fields. Multi-language SEO friendly images are good to go. Creating a new page from one of your templates? Translate your title, and also translate your page name for native language URLs. (Not available for Russian, Chinese, or Japanese languages due to URL limitations). These can be changed in the "Settings" tab for any page as well so whether you're translating new pages or existing pages, you control the URLs everywhere. Language configuration pages are no different. Translate the names of your languages and search for both Site Translation Files (including all of your modules) Translate all of the static text in your templates as well. Notice that the placeholders are retained. DeepL is pretty good at recognizing and keeping non-translatable strings like that. If it is changed, it's easy to fix manually. Fluency adds a "Translate" item to the CMS header. When clicked this opens up a modal with a full translation tool that lets the user translate any language to any language. No need to leave the admin if you need to translate content from a secondary language back to the default ProcessWire language. There is also a button to get the current API usage statistics. DeepL account owners can set billing limitations via character count to control costs. This may help larger sites or sites being retrofitted keep an eye on their usage. Fluency can be used by users having roles given the fluency-translate permission. It couldn't be easier to add Fluency to your new or existing website. Simply add your API key and you're shown what languages are currently available for translation from/to as provided by DeepL. This list and all configuration options are taken live from the API so when DeepL releases new languages you can add them to your site without any work. No module updates, just an easy configuration. Just match the language you configured in ProcessWire to the DeepL language you want it to be associated with and you're done. Fluency also allows you to create a list of words/phrases that will not be translated which can prevent items such as brands and company names from being translated when they shouldn't Limitations: No "translate page" - Translating multiple fields can be done by clicking multiple translation links on multiple fields at once but engineering a "one click page translate" is not feasible from a user experience standpoint. The time it takes to translate one field can be a second or two, but cumulatively that may take much longer (CKEditor fields are slower than plain text fields). There may be a workaround in the future but it isn't currently on the roadmap. No "translate site" - Same thing goes for translating an entire website at once. It would be great, but it would be a very intense process and take a very (very) long time. There may be a workaround in the future but it isn't on the roadmap. No current support for Inline CKEditor fields - Handling for CKEditor on-demand hasn't been implemented yet, this is planned for a future release though and can be done. I just forgot about it because I've never really used that feature personally.. Alpha release - This module is in alpha. Releases should be stable and usable, but there may be edge case issues. Test the module thoroughly and please report any bugs via a Github issue on the repository or respond here. Please note that the browser plugin for Grammarly conflicts with Fluency (as it does with many web applications). To address this issue it is recommended that you disable Grammarly when using Fluency, or open the admin to edit pages in a private window where Grammarly may not be loaded. This is an issue that may not have a resolution as creating a workaround may not be possible. If you have insight as to how this may be solved please visit the Github page and file a bugfix ticket. Requirements: ProcessWire 3.0+ UIKit Admin Theme That's Fluency in a nutshell. A core effort in this module is to create it so that there is nothing DeepL related hard-coded in that would require updating it when DeepL offers new languages. I would like this to be a future-friendly module that doesn't require developer work to keep it up-to-date. The Module Is Free This is my first real module and I want to give it back to the community as thanks. This is the best CMS I've worked with (thank you Ryan & contributors) and a great community (thank you dear reader). DeepL Developer Accounts In addition to paid Pro Developer accounts, DeepL now offers no-cost free accounts. Now all ProcessWire developers and users can use Fluency at no cost. Learn more about free and paid accounts by visiting the DeepL website. Sign up for a Developer account, get an API key, and start using Fluency today. Download & Feedback Download the latest version here https://github.com/SkyLundy/Fluency-Translation/archive/main.zip Github repository: https://github.com/SkyLundy/Fluency-Translation File issues and feature requests here (your feedback and testing is greatly appreciated): https://github.com/SkyLundy/Fluency-Translation/issues Thank you! ¡Gracias! Ich danke Ihnen! Merci! Obrigado! Grazie! Dank u wel! Dziękuję! Спасибо! ありがとうございます! 谢谢你!
  2. 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
  3. Hi all I need to export all the texts from a website to a translation company (as json or csv or txt...). How can this be done? Of course manually, but this website is huge and it would take me years... Also, as a second step, importing the translation ... Any ideas anyone? Tutorials? Plugins? Thanks for your help.
  4. Here's my Norwegian language pack for ProcessWire. I've been adding translations gradually since 2015. By November 2020 the translations are completed, and up to date with the latest dev version of ProcessWire. For details, go to the ProcessWire Modules page … https://modules.processwire.com/modules/norwegian/ … and/or GitHub: https://github.com/snobjorn/processwire-norwegian-language-pack-nb-no Status: Completed / up to date. Third party and PRO module translations have moved to another repository: The site files have been moved to a new repository for module files in Norwegian. Those translations includes translations for some free and some pro modules, see the complete list at GitHub.
  5. "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?
  6. 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
  7. 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
  8. 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?
  9. 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?
  10. 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?
  11. 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}
  12. 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)
  13. 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
  14. 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?
  15. 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?
  16. 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
  17. 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!
  18. 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
  19. 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
  20. 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
  21. 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?
  22. 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.
  23. 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.
  24. 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!
  25. 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.
×
×
  • Create New...