FireWire

Okay- I did misread that a bit. I will admit that my .htaccess-fu is a bit lacking when it comes to more effective redirects and I'm in a timeline-bind. Should have gotten started on that sooner... Thanks again for this info. Surely will come in handy in the future!

Just want to spell out the solution to save any devs who see this post a little time and jump to the solution. As mentioned Jumplinks does not yet support multilanguage URLs. Trying to redirect "naturally" using Jumplinks will have your multilanguage page redirect to the page in the default language. You will have to create a Jumplink redirect for every language on a page (sorry big site and big language devs). Here's a quick screenshot with some explanations: Here's the gist- create your default language redirects as usual using Jumplinks as designed. For your URLs in other languages, add your source language URL as normal, but when entering the redirect destination, manually add the proper language URL and add the ? to the end of it. This "tricks" Jumplinks and creates a kind of sticky URL which Jumplinks won't replace with the default language URL. Couple of pro-tips after working through this: On your source URL, I highly recommend adding the [/] to the end of your source URLs. This makes the redirect work with URLs that end in a trailing slash and those that don't. Regardless of your chosen configuration for URLs it is always a good idea to account for possible user edge cases. Keep SEO in mind! Ensure that your destination pages have a meta canonical URL tag. Google is very literal when parsing URLs and by adding the ? to your destination page you run the risk of fragmenting your content into 2 URLs. Without your canonical tag, Google may index them separately and it is possible that your pages will compete with each other in search results and possibly replace your nice URL with the URL you appended ? As always, test, test, test. Just wanted to provide a shortcut to the solution in the Jumplinks thread. Happy redirecting!

That's my conclusion as well. I didn't want to tinker with ProcessWire's internal workings so I left that redirect parameter alone. Also can confirm empirically that placing my redirect rules didn't stop Apache from parsing the document after the redirect, which while frustrating kind of makes sense given the gravity of important configurations contained in the file. And I agree about complexifying (new word) htaccess too much. Many thanks for the additional insights.

That solution worked like a charm! Thank you for the compliment on the site. Looking forward to launching it on Friday!

Thanks for that link, I skimmed the pages but there are a few in that post haha. I'm still curious about the it parameter though, any insight on why it exists or what ProcessWire does with it?

I did but it's a multi-language site and from what I understand that module doesn't support that unfortunately.

We're launching a new version of our website and I need to create redirects from old pages to their new counterparts at different URLs. An example rule that I've created is Redirect 301 /solar-energy-for-business /solar-energy/commercial-solar/ However when I visit the redirected URL it shows up in the address bar as: https://staging.renovaenergy.com/solar-energy/commercial-solar/?it=solar-energy-for-business We're creating these redirects for SEO purposes and they need to not have additional URL parameters being added. This line in the .htaccess file is adding the original URL as a parameter. RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] Does ProcessWire use this parameter for a purpose? What is the best way to create these redirects without this parameter?

This has been fixed, the translation tool can be accessed by anyone with page-edit permissions, which was the original intent of the module. Out of curiosity- do you see a need to break down access to the translator tool to a specific permission? I'm curious about that idea but didn't think there was a use case. New version is 0.2.2 - quick link to download the latest: https://gitlab.com/SkyLundy/fluency-processwire/-/archive/master/fluency-processwire-master.zip

Oh I have never really used CKEditor fields in anything other than regular mode. I will update the description of the module with that information and add that to the roadmap. I added a permission to the implementation at the company I work for. I will add that to this module as well. Update should be pushed soon and I'll let you know when that is available

Just found out from a user that the browser plugin for Grammarly conflicts with Fluency and causes errors which prevent translations from working. Grammarly is known to cause issues with some web apps and the company seems to not be interested in working on compatibility (as an example, Grammarly has ignored requests to fix conflicts with WordPress' Gutenberg interface for years). Considering how prevalent these issues are with many sites, this isn't a priority for the module's development. Just a heads up in case this becomes an issue for you or your clients. If you have any insight on this that could help solve the issue please open a ticket on the Fluency Gitlab repo.

Unfortunately I haven't localized the UI yet but that is the next priority item on my list. If you have your primary language set as German and the other language as English, the translation link will still say "Translate from English" but it will still translate from German to English. Right now this issue is purely aesthetic. Here's the language translating from German to English but the translate link saying the wrong text. If you would like to change these now so you don't have to wait for a module upgrade, you can update the text strings located on the following lines in these JS files: Fluency/src/js/fluency.js 153 160 216 473 476 490 Fluency/src/js/fluency_language_translator.js 108 168 By changing the text there the module will then fit your setup. Like I mentioned above, I'm working on having this behave correctly out of the box!

Just doing it for the love of the code. Really striving not to "lock in" hard definitions into the code like formality. A workaround I am thinking about is adding an ability for a developer to configure language/formality association with directions for them to review the API as a step to make it work. Believe it or not, I sent a request to DeepL to see if they have a way to query formality that isn't documented The module is essentially a DeepL API wrapper with a lot of the work being handled by the front-end JS. The module itself is going to go through some evolution before I can push it out for collaboration. I'll add a module method to work with files. I still need to firm up the structure of the data returned from the module's methods and then document it. It would be awesome to see this integrated in with your EditorJS module which looks super awesome! I've got a separate repository for a CKEditor integration that I could use a help with. I set that up over the weekend but haven't really touched it. Just did some skeleton code to add the ability to highlight text and exclude it from translation but it's not even close to useful. PM me and let me know what you think.

Everything is hackable... That would interfere with ProcessWire's existing UI where clicking on a tab that is already selected changes all of the tabs on the page to that language. I don't want the module to alter the native PW interface and take away a feature. I may revisit the idea of translating a field to all languages at once and test it out to see if it is feasible in practice. If I can do that while being able to provide a progress bar or something then I think that would be the way to go. That would take care of the amount of work of clicking for each language, save space, reduce scrolling, etc.

Yes, that is a limitation in the on-page UI. Initial goal is to keep it simple for the user to translate from the primary language with a one click operation rather than needing a select input to choose the source language. I prioritized the translation tool in the menu at the top is to translate content from any language to any language just in case that becomes something that is needed. That was the goal of making the link a modal so that tool can be used anywhere there has to be content translated from any language to any language without leaving the page or tab-hopping. I had the same thought but was concerned about having it stack up against the language tabs if there were too many of them or if the screen was smaller (like in the screenshots in the original post). I could try experimenting with the translation trigger placement in the future but it would be sometime after localizing the UI so more people can use the module.

I'm continuing work on this module as it gets more time in use and any edge case issues pop up. I'm going to be working on fast iterations while in alpha to address problems quickly so the module can get to a formal release. If you download and test/use the module please submit any issues via the Gitlab repo so it's on my radar. Be sure to check for newer versions on the master branch to get the latest stable version. The next push to master will contain a changelog so early users can track changes and decide if a module upgrade is needed. Thanks again to those who are able to help! Here's the link to the repo: https://gitlab.com/SkyLundy/fluency-processwire

That's excellent to hear! Glad it came in time. I'm going to be launching a site that uses it in the next few weeks as it is stable and useful right now. It should have more features and time in production by the time you use it! If you get any time to play around with it or use it in the meantime I would love to hear feedback and any bugs you find. Cheers!

There's a link for that in the module config page. Was hidden in the screenshot for simplicity.

@bartelsmedia Back with good news a year and a half later... I am working on a ProcessWire DeepL integration. I just posted details about it today with a full rundown, screenshots, and an alpha version download. This thread stuck with me and I kept checking back with DeepL to keep tabs on their API availability and as of spring 2020 they are allowing subscriptions from within the US. It only costs $5.49 per month and is worth every penny. I'm going to be launching a new website for our company in the next few weeks so I'll be using it in production and refining it. Really glad this came in time for that project because it's going to save a lot of headaches! If anyone wants to spend a couple of bucks on an API subscription, download the module, and help out with testing it would be great to get feedback. Read more about it here on this post

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. Fluency is available in the ProcessWire Modules Directory and on Github 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 third-party translation service 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 TinyMCE or CKEditor (inline, or regular) Translate page names/URLs Translate in-template translation function wrapped strings Translate modules, both core and add-ons 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 those offered by the third party translation service you choose. Currently Fluency works with DeepL and Google Cloud Translation. 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 translate 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 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 a long-standing issue in the larger web development community and 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. Enhancements Translate All Fields On A Page Compatibility with newest rewrite of module is in progress... An exciting companion module has been written by @robert which extends the functionality of Fluency to translate all fields on a page at once. The module has several useful features that can make Fluency even more useful and can come in handy for translating existing content more quickly. I recommend reading his comments for details on how it works and input on best practices later in this thread. Get the module at the Github repo: https://github.com/robertweiss/ProcessTranslatePage 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. 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ę! Спасибо! ありがとうございます！ 谢谢你！

Having a rough go with performance and figuring out how to diagnose issues. I noticed that as I was building out a template that the load times on my local dev environment continued to get slower and slower. Basically slower than browsing the internet. I recently picked up the Pro DevTools modules and started working from the Profiler and the results have been pretty bad. I'm using the Twig Template Engine. It is taking ~1.5 seconds for the server to render the page before returning anything to the browser. I started to work backwards through my code and I cannot find where there would be issues that should be causing this much of a slowdown, I wasn't able to get speed differences by disabling modules and I don't think that I'm running anything that would conflict. I went through my templates and partials and started commenting out loops. I have a few loops on the home page to render picture grids, a blog feed, and navigation in both the footer and the header. There aren't any calls to modules or special functions that are happening inside these loops. When studying the output of Profiler there's no indication that anything is booting up during the page rendering process either. By commenting out all of the loops it dropped the render time from ~1.5s to .3-.5s, which is still slow for ProcessWire. I've attached two screenshots of the Profiler output for comparison. Everything below the cutoff in the picture had zero execution time. I'm not experiencing any slowdown on other local sites. Appreciate any help! Currently running: ProcessWire 3.0.164 Master TemplateEngineFactory v2 TemplateEngineTwig v3 PHP 7.3.13

Changing the method visibility fixed the issue. I don't know how I overlooked it. This is officially the most embarrassing thing I've posted on any support board... ever. Ha! That was totally an accident as I've written other page classes and minded the private/public declaration. Hope this ends up helping others! Thanks!

Hey all. I'm having an issue with the new custom page classes feature which is a fantastic tool. I am running into a recursion issue when attempting to call a custom page class. I have a class called BlogPostPage.php (for blog-post.php) which contains a method called getSummary(). That method gets a summary field or truncates the body in it's absence. I've attached photos of the template code, custom page class code (which I've simplified for testing), and the PW output error. There is no recursion in the getSummary() method. This error occurs whether I output multiple blog posts in a loop or if I output one blog post with no looping in my template code. In use: ProcessWire 3.0.164 dev PHP 7.3.13 I am also using the Template Engine Twig module which has not caused any errors or issues thus far. Many thanks!

^This guy! Big thanks to that effort on your part. Another reason to love the PW forums... Here's something that would be pretty great- a companion to the Modules directory that serves to be a repo for snippets like this. I know there are a lot of people whipping up fixes for odds and ends that never got a proper module, are a module but need more work to integrate, or don't need one at all to work. Like a place for pure ProcessWire gists- or even just a directory of links to gists. If you want to whip that up and reply with it that would be great ?

Well- I live in California and I heard about the CCPA (California Consumer Privacy Act) and had to look it up. When I found the rules it put in place I remembered why- the requirements for entities having to comply with it are well outside of most companies. (Sharing the details here for anyone who stumbles upon this thread). Businesses that earn $25,000,000 or more a year in revenue Businesses that annually buy, receive, sell or share personal information of 50,000 or more consumers, households or devices for commercial purposes Business that derive 50% or more of its annual revenue from selling consumer personal information Basically- Google, Facebook, Twitter, etc. are located here in California and this was targeting them. Apart from that politicians in America and the states within it basically dilute legal measures or do nothing at all. We're lucky in California we even got that. I also had to look up the EU-US privacy law and from what I understand that was basically the U.S. telling the EU that their privacy laws do not protect any American citizen in the EU (surprise). You're totally right about American companies operating with respect to actual EU citizens though.

Never knew about that module. Good share. Outside of having the manually coded implementation, an integrated approach would be great for those who aren't strong back end developers and wouldn't be comfortable digging into hooks. There is value in the behavior. One of the big draws of PW is it's raw power combined with ease of use which puts this kind of feature within the hands of developers like you and I but beyond many others. I couldn't find this module being listed anywhere that could be found. Is it something that you put together? If it's used by someone then having proper attribution is something that would be a good practice to keep going (myself included). Thanks again for the share.