module Fluency - The complete translation enhancement suite for ProcessWire

[Klenkes]

@markus-th You are correct! A downgrade to 1.0.8 works!

[FireWire]

@Klenkes @markus-th Addressing issues that pop up when upgrading the module have been difficult since changing how data is stored. Can you confirm that after updating that you checked the module configuration and confirmed that all of the settings are correct?

Can you download and test the version I just pushed to the dev branch? This one works for me and has changes that may address the issue.

[Klenkes]

On 7/24/2024 at 9:10 PM, FireWire said:

Can you confirm that after updating that you checked the module configuration and confirmed that all of the settings are correct?

@FireWire In my case it was a new install with Fluency 1.0.9. No module update!

[FireWire]

@Klenkes Well that's even worse...

Can you confirm if the dev branch version resolves the issue?

[Klenkes]

@FireWireSorry, but the DEV Version doesn't work at all for me...

After the upgrade I went to the modules settings page and configured everything.
After I hit save the following error message appeared:

There are no translation buttons in page edit shown. No other error messages.

The fields for the default language like in previous versions is missing?

Mhh...

[FireWire]

@Klenkes That's a ProcessWire error for a field that is missing a value, not a Fluency error. Can you confirm that there are no empty required fields on the Fluency module config page? Fluency will not show any translation buttons unless the module has been properly configured.

[Klenkes]

@FireWire I had to logout and login again. Then all fields were visible in the module config. At first the Language Associations fieldset wasn't there, and Fluency Options.

Now it works as expected!

[elabx]

Hi crew! Does this field work with SEO Maestro? Thanks!

[FireWire]

@elabx Si.

[nurkka]

In my current project, the default language is German and the second language is English. Now, I am using Ryan's LoginRegisterPro module, which is of course in English. I wanted to use Fluency to translate all fields in the language translator to German, but that's not possible. This is because Fluency does only translate from the first to the second (and other) languages, but not from "string constant in a php file" to the first language. At least in my case, it always copied the string constant into the field, which is in English.

So, I changed my setup and made the default language English and the second language German, and now it worked: Fluency translated all strings from the module php file to German in one step.

But now, I have the problem, that I can't leave the website with German as the second language, because to my knowledge that's only possible, if one has language tokens in the urls, also for the default language, and makes a redirect to the desired language. But that's no option in this project. Setting the guest user language to the second language (now German) didn't help either.

My workaround now is, to export the translated JSON files, then switch the languages back to default = German and second = English, and import the translated JSON file(s) to the German language.

So I have some questions:

- Has anybody already found a better solution for this problem?

- @FireWire Would it be possible to add a feature to Fluency, to be able to translate module or template files (which are mostly in English) also to the default language (for cases where it is a non-English language)?

[FireWire]

@nurkka

I haven't thought of that situation before. That would take a whole different approach to translation by manipulating the language files directly because there's no way to get the translated strings from another language. There's an experimental feature in Fluency to translate any file or files in ProcessWire (core, module, template, etc.), unfortunately it only translates from the default language. It is possible to do what you're asking, but I am too overloaded with work right now to implement it. I do see the value though and would like to make that a part of Fluency in the future and the file translation that is already present would make it possible.

If you wanted to experiment with bulk translations and still work with importing/exporting the JSON files, check out the $fluency->translateProcessWireFiles() method. Docblock has full usage explanations starting on line 494 in Fluency.module.php.

[monollonom]

3 hours ago, nurkka said:

But now, I have the problem, that I can't leave the website with German as the second language, because to my knowledge that's only possible, if one has language tokens in the urls, also for the default language, and makes a redirect to the desired language. But that's no option in this project. Setting the guest user language to the second language (now German) didn't help either.

In your home page can't you set the English page name as /en/ and leave the German one as / ?

Edit: just tried and turns out you can't, as it automatically set the name to the main language's one of you leave empty

Edited August 10 by monollonom

[FireWire]

Version 2.0 released. Please review the notes on upgrading from versions before 1.0.8 below.

This version provides bugfixes and is recommended for everyone.

In version 1.0.8 changes were made to how Fluency stores configuration data to address issues where ModSecurity rules may be tripped in some server environments. Despite my best efforts there have been issues experienced by some users when upgrading from earlier versions to 1.0.7 or earlier. They have been difficult to reproduce and fixes have worked in some instances but not others.

Fluency has been bumped to version 2.0 since these the changes have proven to be breaking.

If you are upgrading from any version before 1.0.8 to any version 2.0.0 or later it is highly recommended that you fully uninstall, download and move the new version to the modules folder, then reinstall Fluency. Upgrading from 1.0.8 or later does not require this step.

There is no danger to your site's content but you will have to reconfigure the module. This includes choosing your Translation Engine, entering your API key, and configuring your language associations. If you don't have immediate access to the API key you have been using, temporarily copy/paste that key into a separate location and re-enter it after reinstalling the module.

I'm not able to provide any support for upgrade issues since this is the identified solution as a preventative measure.

In the unlikely event that you still experience issues you may need to check that all Fluency related database tables were removed when uninstalling Fluency. These are probably edge cases, but that is the surefire way to address any problems.

Thank you for your patience, understanding, and helpful feedback!

[ryangorley]

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?

[FireWire]

@ryangorley Got you covered. There are no hard-coded languages in Fluency but getting the translatable languages involves an API call that can slow some things down during regular module use. Fluency caches available languages until cleared when you need to refresh the list, as in your case.

Head over to the Fluency module config and scroll down to "Fluency Options" then nuke the translatable languages cache. Once you reload the page Fluency will retrieve and re-cache all of the latest language data and you should be good to go.

Click button to light fuse, then run for cover:

 

[FireWire]

@ryangorley I'll leave that response up in case it helps anyone else but I just took a look at the DeepL website source code and it shows that it translates into Traditional Chinese which is ISO code zh-Hant, but the API is returning zh-Hans which Simplified Traditional Chinese. I think this may be where the disparity may be coming from.

Here's the HTML used on their home page translation tool. They are providing full Traditional Chinese translation via the web, but not via the API (no idea why)

<div data-testid="translator-target-lang" dl-selected-lang="zh-Hant" class="mobile:hidden truncate">Chinese (traditional)</div>

So your best bet is to use zh-Hans in Fluency as that's the closest they offer via the API.

I jumped onto an installation of Fluency on my own to check that out but jumped the gun with the translation cache reply...

 

[ryangorley]

@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!

[FireWire]

@ryangorley No problem and no worries. The info here may always help someone else!

[ryangorley]

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.

Edited October 16 by ryangorley

[FireWire]

@ryangorley That's interesting... My first thought is that the AJAX request is attempted but there is an error page returned by ProcessWire before the module is able to respond(?) There aren't any methods that would return an HTML page so that "<!DOCTYPE" fragment is possibly coming from an error page.

Struggling to think what could change when moving between environments would cause this to happen.

[ryangorley]

2 hours ago, FireWire said:

@ryangorley That's interesting... My first thought is that the AJAX request is attempted but there is an error page returned by ProcessWire before the module is able to respond(?) There aren't any methods that would return an HTML page so that "<!DOCTYPE" fragment is possibly coming from an error page.

Struggling to think what could change when moving between environments would cause this to happen.

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!