ryangorley

No worries! If no one else has reported this issue, perhaps it's a host specific issue. It's pretty easy to set the plugin up, so not a big deal. Thanks for the fantastic plugin!

Not a burning issue, but when I migrate a site and DB between production and dev I get this error in the console log: fluency.bundle.js:194 [Fluency module API failure] Unexpected token '<', "<!DOCTYPE "... is not valid JSON u @ fluency.bundle.js:194 Promise.catch getTranslation @ fluency.bundle.js:140 (anonymous) @ fluency.bundle.js:2876 Once I uninstall and re-install Fluency it seems to work again. Just curious if you have any ideas what may be causing this issue or if there is an easy fix. If not, again, this isn't a serious problem, just an inconvenience. Note: By migrate I mean that I am running an rsync on the template/asset directories from one to the other and doing a complete DB dump and import.

@FireWire I feel bad, because there is a note at the top of the DeepL documentation page that says Traditional isn't yet available via the API, but I guess it will be at some point. Sorry for the false alarm, and thanks for looking into this!

Hey @FireWire, thanks again for this great module. Quick question. I'm not seeing Traditional Chinese as an option. It was recently added to DeepL. Does that need to be enabled in some fashion on your end?

Thanks @wbmnfktr! Yes, these are using ProCache. I forgot to mention that one, though I worked very hard to ensure uncached pages would be fast upon first visit, which I'm very satisfied with ProcessWire they are.

Hey All, I thought I'd jump on here and share my first 3 ProcessWire sites! LatticeWork (https://www.latticeworkinc.com/) - This one is live but still being actively developed in preparation for targeting an international audience (so current translations need auditing and it's not yet GDPR-compliant). The multilingual capabilities offered by ProcessWire, in contrast to WordPress, were the catalyst for starting my PW journey. The added performance that will be necessary as we deprecate some international sites and push everyone here was another decision driver for choosing PW. Obviously many thanks to @ryan and other core contributors for such an incredibly refined core product that regularly surprises me with features and functionality that I didn't know I was missing. Additional thanks go to @FireWire for the Fluency add-on, @Mike Rockett for Jumplinks, @Wanze for SEO Maestro, @teppo for Search Engine, and again Ryan for Pro Fields. These were invaluable. The Mart Group (https://www.martgroup.com/) - This site was my second to build with ProcessWire, though it was completed first due to its smaller size. In addition to all the prior thanks, I really appreciated RockFrontend by @bernhard while working on this one. Lori H. Cole (https://www.editsbylori.com/) - I probably wouldn't mention this single-page site I built as a favor, except to point out that PW is so lean and easy to work with I was able to give the client the ability to edit their own site without much server overhead or added development time. I did the front-end development work on these, which as a designer/animator hasn't historically been an area I'm comfortable in. ProcessWire has been such a delight to use that it has re-kindled my interest in working more with code. So, in time I hope to get more creative with the front-end coding as well. Thanks!

I'll add, perhaps for @ryan to consider, that an equally good solution would be for ProcessWire to borrow a behavior from elsewhere. In WordPress if I want to reset a slug I just clear the field and save the post. It then auto-populates that field from the post title as it does when the post is first created. In ProcessWire clearing the slug fields and saving the page just reverts the fields to their prior state. A small, but nice feature in WordPress I'd love to see in PW. :)

So, I've bumped into something worth considering. When I added more languages to my client's site the existing pages inherited the untranslated URL slugs from the default language. So I've got to go to the Settings for each page and manually click the translate from English button for each language to pull a translated slug. That's burdensome, but it seemed to be working... until I had to start translating a bunch of blog tags, then some slugs wouldn't translate. I couldn't figure it out until I realized that Fluency must be pulling a DeepL translation from the English slug, not the English title. You'd think it wouldn't matter, but it does. Here's an example: English > French: AI App > Application IA ai-app > ai-app It turns out DeepL translates ai-app to ai-app in every language. I don't think it knows what ai-app means so it just returns it. I don't know how commonly people will run into this problem, but I've been running into it a bit. Sometimes DeepL will return the slug unchanged, sometimes it will provide a slightly different translation than it did for the title. My suggestion would be for the slug translation prompt to use the default language page title when calling for a translation. I could see where pulling the title could create other surprises, such as when someone has the page title "Contact Us" but the slug "contact" they'll be getting longer slugs returned. Still I think that would be preferable to DeepL just silently failing. Maybe others feel differently. It's worth consideration though.

@FireWire Got delayed on my end, but I've uploaded and tested the update. It's working great. Thank you!

Thanks! I'll be able to test that tomorrow afternoon.

Okay, so I'm a little late on the testing side. I love the update! I'm having one issue, which probably has nothing to do with 1.07. The site I'm working on needs to be translated to Traditional Chinese for Taiwan (zh-tw) which isn't currently supported by DeepL and will have to be done manually. However, if I try to use Fluency when this language is added to the site it breaks with a console error: Uncaught TypeError: Cannot read properties of null (reading 'engineLanguage') at HTMLAnchorElement.<anonymous> (fluency.bundle.js:2812:110) Now, I presume this is because the language isn't mapped to anything in the Fluency module config. The behavior I would expect from Fluency is to just skip translations for languages not mapped, but that's not what it appears to be doing. Is that actually the problem, and is it something easily changed?

@FireWire At first glance, this looks great. I'll pull that dev branch version down and test it out as soon as I can. Thanks! Hopefully someone here has a good idea for the second issue. [fingers crossed]

@FireWire I'm still loving the convenience of this module, thanks! I've got a couple questions: When we add new languages to a site soon we're going to have empty language fields all over. If we use "translate to all languages" again to populate these blank language fields any manual edits to existing languages will be overwritten. How easily could the "translate from English" button be added back to co-exist alongside the "translate to all languages" button, so we could just pull individual translations without altering others when needed? Currently when a page is created and I translate the title, I'll have to add a space at the end of each translated title to prompt the page URL to reflect the translation. Would this be difficult to trigger automatically? If these are non-trivial changes, let me know what it would cost to sponsor the work. Thanks!

@FireWire This plugin has saved me so much time with a site I'm building for a client. Is there anywhere I can sponsor you or a way to send a few bucks your way?

@teppo I just wanted to let you know this plugin saved my life today. Thank you for building it! I just became a sponsor :)