module Fluency - The complete translation enhancement suite for ProcessWire

[bernhard]

@snck yeah that's likely the change detection in RPB not recognising the change. Sounds like it would need a fix in RPB not in fluency. Do you have the latest version of RPB? There have been some changes in change detection, one of them coming from @FireWire himself 🙂 

[Tiberium]

@bernhardI want to say, that I have the same (or similar) problem: 

Quote

There have been some changes in change detection,

On which version where this?

[FireWire]

9 hours ago, snck said:

Thank you so much for your explanation and patience.

No problem at all, thank you for asking detailed questions and providing extra information. It helps troubleshoot!

9 hours ago, snck said:

I uninstalled the module, reinstalled it

Did you install this module for the first time when you saw these issues or did they happen during a module upgrade? There were some finicky issues a couple of versions ago when upgrading that unfortunately can only be resolved with an uninstall/reinstall, but that should not happen when upgrading to recent versions.

Out of curiosity, if you upgraded, what version did you upgrade from?

[FireWire]

On 7/24/2025 at 8:51 AM, Tiberium said:

I want to say, that I have the same (or similar) problem

I am sporadically seeing this issue and it's difficult to detect why/when. When I get a chance I will take another look at how Fluency can help.

@bernhard I'm still convinced that this isn't a problem with RPB and the measures that you/we have worked to to address this have been very robust. RPB is at no fault if changes to Inputfields are not properly being signaled by a class change or event. So the fixes in RPB seem to work partially but there are edge cases- why though I am not 100% sure of. The following is my best guess (we shall see for sure).

I (pretty recently) found out that jQuery events are completely isolated from vanilla JS events. Events dispatched from vanilla JS do not trigger listeners in jQuery and vice versa. jQuery hasn't been part of my workflow for many years and dispatching jQuery events is an extra step that modules that do not use jQuery must take when necessary. Another native behavior of vanilla JS is that programmatically setting the value of a field does not trigger a change event, which is the reason all of this matters to begin with, so RPB and PW Inputfield listeners will not be triggered. For the record, Fluency has only ever dispatched vanilla JS events.

Rather than try and track down why some changes are caught by ProcessWire/RPB, I'm going to take another crack at a solution.

@Tiberium to bypass this you'll need to translate a field then manually click through the language tabs and add something like a trailing space to the content in each. ProcessWire trims leading/trailing spaces on save so this won't affect your content. This is annoying but it ensures that the changes to the field content are registered by both ProcessWire and RPB via a UI interaction.

Thanks to all for your patience! Improving software one bug at a time...

[snck]

On 7/24/2025 at 8:19 PM, FireWire said:

No problem at all, thank you for asking detailed questions and providing extra information. It helps troubleshoot!

Did you install this module for the first time when you saw these issues or did they happen during a module upgrade? There were some finicky issues a couple of versions ago when upgrading that unfortunately can only be resolved with an uninstall/reinstall, but that should not happen when upgrading to recent versions.

Out of curiosity, if you upgraded, what version did you upgrade from?

I installed the module for the first time (v2.1.1), no upgrade process involved. 😬

[FireWire]

1 hour ago, snck said:

I installed the module for the first time (v2.1.1), no upgrade process involved.

Thanks for sharing, good to know. I'll keep an eye out to see if this happens more.

[FireWire]

New dev version of Fluency with fixes to address RockPageBuilder compatibility issues. Translating content within blocks should now save correctly.

@bernhard @snck @Tiberium If you are able to test it would be a big help so I can merge this into a new release. I've tested this on text, textarea, TinyMCE (normal/inline), CKEditor (normal/inline), as well as image description fields. This should cover all multi-language fields.

Download the .zip from dev and replace the entire folder (not copy/merge) in your modules directory.

https://github.com/SkyLundy/Fluency/tree/development

[Tiberium]

Hmm I was about to test it, on the specific customer project, who had that problem and now I'm hit on the 

Quote

Translation rate limit exceeded, please wait then try again

Problem in the plugin configuration screen. So Fluency will not more let me connect the languages from ProcessWire to the DeepL one, and so I can not test it. Sorry. If it helps, the TranslatePage (via DeepL) - Plugin on the other hand, has no problems with the same API-Key.

[FireWire]

@Tiberium This seems like a new issue that has happened to you and one other person over the past couple of weeks. There haven't been any changes to how Fluency interacts with the API for years. The API use to rate limit translations but now it looks like it rate limits all endpoints(?) What is odd is that only you and one other person have experienced this, or at least reported it here on the thread. I had to repeatedly hit the API endpoint 3-5 times to replicate the issue.

I've updated the code to account for this but it is difficult for me to check since I have to create artificial conditions to replicate the problem. Can you test the code from this branch? Many thanks!

[Tiberium]

@FireWire unfortunate, that doesn't solve it.

I remove (+delete) the plugin, refresh the modules and then installed the apiDeleay branch.

What is a difference, between TranslatePage and Fluency is, that you have to connect the locals manual, in the language page:

The fluency "way" is more comfortable, but since that is the curlprint, would be a fallback option reliable? Like to deactivate the automatic calling for language options and set it manual? Or is that a "Correlation vs. Causation" observation from my side?

 

==========

Thank you for taking the time and publish testing branches! I know it is very hard to debug something, that is not seeing on the own side.

[FireWire]

@Tiberium I have another way to attack this so I'll put together another commit on that branch and let you know.

Unfortunately adding an ability to manually assign languages like the TranslatePage module would be a heavier lift than you might think since there are more features that Fluency uses. It would require rewriting the module config page for DeepL. The true solution is to make sure that the module performs correctly for everyone and preserve the UI that people are familiar with. It wouldn't be a good move to require some people who are having difficulty with API calls to forego features that are available to others who aren't.

So I want to get this right for everyone 👍

Hold tight, I'll come back with another test. Please expect that via private message so we can more easily converse without adding too many more posts to this thread. When the issue is solved I'll come back and post a new release.

 

[DV-JF]

@FireWire Would you have a look at https://github.com/SkyLundy/Fluency/pull/19 - there's a litte syntax error for x-default.

[FireWire]

@DV-JF I swear I thought I fixed that in a previous version... Thanks for the PR. I'm tidying up some updates and will include in the next forthcoming release.

[FireWire]

@DV-JF It's already merged with main but will be noted in the next release with credit for your contribution. Thanks again!

[Mike-it]

On 7/24/2025 at 10:24 AM, snck said:

@FireWire Thank you so much for your explanation and patience. I got four requests every time I loaded the settings page. I uninstalled the module, reinstalled it, entered the same settings, saved them (2 times) and out of a sudden it worked. I am able to configure the languages and translate. Great experience so far! 👍

One quick observation: I am using @bernhard's RockPageBuilder. In a gallery block that contains multiple images (Pageimages field) I wanted to translate the descriptions. Translating them works as expected (translation is shown in the field), but after saving (clicking Save button or pushing Return key) the field is empty again (translation gone). If I change the field's value (before or after translating), the translation is saved as expected. I noticed that whenever I manually change something in the description field, .InputfieldStateChanged class is added to the inputfield wrapper (#wrap_Inputfield_rpb_gallery_images_repeater1613 in this case), but not if I just click the Translate link. I suspect that the change in the description field is somehow not detected correctly and not saved in consequence? Maybe there is a way for Fluency to trigger the detection of that change?

@snck @FireWire Really sorry for the late reply. The same thing happened to me. I simply tried again a few days later on the same website with the same credentials, and the error didn't occur again... Now i got the same error on a new site, and, i hope the same thing (uninstalling and saving) happens again (I have zero character usage on my account)...

looking in browser console i have some errors:
GET mysite.com/admin/page/fluency.bundle.js?v=3.0.246
NS_ERROR_CORRUPTED_CONTENT
and
The resource from “mysite.com/admin/page/fluency.bundle.js?v=3.0.246” was blocked due to a MIME type mismatch (“text/html”) (X-Content-Type-Options: nosniff)

[FireWire]

@Mike-it I'm going to have to guess that this is a server issue that is unique to your environment. There's nothing that Fluency could do to change how the server delivers the JS file. The second error mentions the header which means that the way that your server is delivering the file to the browser is causing a problem because the browser is expecting a "text/html" document and the MIME type for a JavaScript file should be "text/javascript".

Here's a stackoverflow thread discussing this same issue for JS. This is difficult for me to help diagnose since this is a one off issue that seems to be related to the server you're using rather than an issue with the module. If it's not happening in your development environment but it is happening in production then that also points to a server configuration issue.

[cst989]

I think the content type might be a red herring. A similar thing happens to me in a DDEV setup... seems to be trying to download the JS file from /manage/page/edit/fluency.bundle.js?v=3.0.227. At this point ProcessWire 302s to the bookmarks webpage, which likely explains the MIME type mismatch.

If I look in the code, it tries to load the js path from {$this->moduleJsPath} however if I dump that on my page, it returns nothing - so effectively it's trying to load the js file from <current_url>/fluency.bundle.js

Since they should be set in init(), I guess this is not firing?

This is my first time trying a multilingual site, I've only done the following so far:

• On an existing 3.0.227 PW site running PHP 8.2
• Install language fields, language names and language tabs modules
• Added a second language
• Installed Fluency
• Added a Google Cloud API key
• Converted my title field to Title Multilanguage
• Edited a page

There's no option to use Fluency with the title field, I only see the JS errors in console 

 

Edited 3 hours ago by cst989