module Fluency - The complete translation enhancement suite for ProcessWire

[bernhard]

PS: Thought it might be translation cache, but just flushed the cache and I get the same (wrong) translation 😞 

[FireWire]

@bernhard That's definitely a bug. Investigating.

[bernhard]

@FireWire thank you very much!

Another little detail I just found: I wanted to translate "Telefon" to EN + CZ. For EN it's "Telephone", fine.

For CZ it seems to be "Telefon", the same as in German:

Now the problem is that if it is the same and it is saved like this, the field's value is lost:

Not sure if that is an issue with your module or rather an issue for Ryan? What do you think? I think it's more a thing that should be handled by the core. When the field is filled out and the same as the default's language value, I think it should automatically save as "+" which tells PW to use the same value as the default.

[FireWire]

@bernhard Haven't forgot about your request! The event for the organization I'm working with kicks off this week and it's been just a little hectic haha.

  On 2/4/2025 at 5:53 PM, bernhard said:

Not sure if that is an issue with your module or rather an issue for Ryan? What do you think? I think it's more a thing that should be handled by the core. When the field is filled out and the same as the default's language value, I think it should automatically save as "+" which tells PW to use the same value as the default.

Expand  

I just checked and the language page says to use an '=' sign to designate tell PW to use the default language.

When I entered that it saved the = sign. Am I talking about the same thing?

[bernhard]

Oh, I was always using + instead of = and it worked as well. Not sure where I picked that up.

  On 2/7/2025 at 7:24 PM, FireWire said:

When I entered that it saved the = sign. Am I talking about the same thing?

Expand  

Yes, manually entering it saves it. But the issue is that when you translate a string and the returned translation is the same (eg Telefon (DE) --> Telefon (CZ)) then fluency will fill the input with "Telefon" which will then be lost on save and the field will be marked as "blank".

I think it would be good if it turned "Telefon" into "=" on save. But I think that the core should take care of this! What do you think?

PS: No hurry.

[FireWire]

It makes sense to me that if ProcessWire will remove the value because it is the same then it might as well replace it with = .

I think it would be a nice indicator visually and to prevent extra characters being used when translating. There would be no way for Fluency to know that a blank field indicates a match. Never thought about that before, good catch!

[bernhard]

  On 2/3/2025 at 5:56 PM, bernhard said:

Hey @FireWire any idea why this is not working:

Never used this feature before, so I might be doing something wrong?

Thx for your help!

Expand  

Hey @FireWire any news on this? Can you reproduce the bug? Let me know if I can help with anything!

[FireWire]

@bernhard Sorry for the delay! The event just started (the one that I built the site for) and it's taken over my life for the moment. I have a fix in the works, I just need to button a couple of things up. Plan for having it ready by this weekend. I'll post back here when done!

[bernhard]

Hey @FireWire great thank you! My project is taking shape and we will start adding content soon, so it's a bit annoying if the translation service breaks our site snippets 🙂 Great to know that you can reproduce and a fix is coming 🙂

All the best for your event!

[FireWire]

@bernhard Apologies for the delay! I've pushed updates to the dev branch. I had a few changes that were already going into the next version that I had to do some extra testing for and a lot of housekeeping.

Let me know if this works as well for you as it did me and I'll push another version to main https://github.com/SkyLundy/Fluency/tree/development

New feature that some may be interested in- adding DeepL languages for translation that are technically supported by their API but not delivered by the languages endpoint yet. You can read more about when that happens and why on this DeepL documentation page.

To manually define languages in Fluency that are supported for translation, you can use a hook. This will make the language available both within the global translation tool as well as available for configuration with a ProcessWire language on the module config page.

<?php namespace ProcessWire;

// ready.php

use Fluency\DataTransferObjects\{EngineLanguageData, EngineTranslatableLanguagesData};

// Hook after Fluency gets the available languages from the DeepL API

wire()->addHookAfter('Fluency::getTranslatableLanguages', function (HookEvent $e) {
  
    // $e->return is an instance of EngineTranslatableLanguageData
    // The `languages` property returns an array of EngineLanguageData objects
    $languages = $e->return->languages;

    // Create a new data object, define the values according to the API docs, add it to the original languages array
    $languages[] = EngineLanguageData::fromArray([
        'sourceName' => __('Arabic'),
        'sourceCode' => 'AR',
        'targetName' => __('Arabic'),
        'targetCode' => 'AR',
        'meta' => [
            'supports_formality' => false, // This is determined by DeepL, check to see if it's available in their API docs
        ],
    ]);

    // Instantiate a new EngineTranslatableLanguageData object with the language array then assign it to the return value
    $e->return = EngineTranslatableLanguagesData::fromArray([
        'languages' => $languages
    ]);
});

@Hari KT This is a new method supported by Fluency to add Arabic to Fluency before DeepL lists it for translation. Thank you for inspiring a solution with your Github issue on languages not being available in Fluency. This is available on the dev branch of the Fluency repo if you would like to help test it out

@ryangorley This will address the issue you had with Traditional Chinese, albeit a lot later than may be useful for you, but the hook above can be modified to resolve that problem. I'm surprised how long the language had been listed as "available soon" on their API documentation 🤷‍♂️ I would have gone this route sooner had I known there was some documentation about this, I don't think it existed at the time.

[bernhard]

Hey @FireWire thx a lot for your work on this. Unfortunately it still behaves the same:

HA! I found the issue when making the screenshot for this post:

I realised the note below the field! Didn't see this before and expected the textarea to take one string per line!

--> now it works as expected!

Any reason why you did not make this textarea behave like "one word per line"? That would be a lot easier to read and a lot easier to type imho 🙂 

[FireWire]

  On 2/26/2025 at 12:17 PM, bernhard said:

Any reason why you did not make this textarea behave like "one word per line"? That would be a lot easier to read and a lot easier to type imho

Expand  

Sorry about that, I didn't think of that and nobody ever mentioned it before 🤔

I can add that.

[FireWire]

@bernhard Your wish is my command 🧞. Dev branch has one string per line entry for globally excluded strings on the module config page.

[bernhard]

Awesome! Thank you! And shame on me - I have not yet given the module a star on github 😮 

[FireWire]

@bernhard It's never too late to star a repo 😎 Thank you!

[FireWire]

Hey everyone!

Fluency v2.1.0 has been released with new features and bugfixes.

• Translation cache now caches translations permanently until cleared on the module config page when translation caching is enabled.
• Some Fluency methods are now hookable. Refer to README for documentation and use case. Credit to @Hari KT for inspiring this feature.
• Globally excluded strings can now be entered either one per line or all on one line separated by a || (double pipe). Credit to @bernhard for the feature suggestion
• Translating static strings using the ProcessWire translator now offers the ability to specify the language code to be used for the source language
• Fix issue where strings configured to be excluded from translations on the module config page were being translated. Credit to @bernhard for finding and reporting
• Correct issue where custom language code field that may optionally be added to ProcessWire language pages was inconsistent and incorrectly documented.
• Fix missing localization strings for some errors
• Various small improvements, some bugs that had not yet affected regular usage

Various housekeeping and code cleanup that only matters if you like reading the source 🤷‍♂️

Thanks all, and please report any issues!

[bernhard]

Thank you for all your work on this great module!

[FireWire]

Hey translators and polyglots!

v2.1.1 has been released to address a bug introduces in 2.1.0 that affected some, but not all, users. If you are experiencing issues please reference this Github issue that may provide more information.

If you haven't experienced any bugs, upgrading is still recommended to prevent any oddities in the future. Unlikely, but safer than sorry. 2.1.1 is available via the modules directory and can be upgraded from the module config page in your ProcessWire admin.

Thank you to @jacmaes, @ryangorley, and others contributing in the Github issue for reporting and assisting with debugging!

[bernhard]

I can only repeat myself. Thank you for that great module!

Today we had the case that the client removed text from a textarea in the native language. When checking the other languages I found that there was still some text there, which we didn't want. So I clicked "edit this block" and then on the empty german textarea I clicked "translate to all languages" in the hopes that it wiped the content of all other languages as well.

But it didn't. So I had to clear all fields manually. Is that intentional? Not a big deal for sure, but I can't think of a use case where clicking on "translate to all" on an empty field should prevent also deleting the other languages values?

[FireWire]

@bernhard I had a response typed out, didn't click "Submit Reply" and just came back find out that you never saw it 🤦‍♂️

Not clearing is intentional. The only way Fluency works right now is to take the source content and make the request to ProcessWire, pull from cache, or make a call to the translator API, then send it back to the client and replace the contents. At one point I think it may have cleared it but I updated the module to prevent taking any action if the source field is empty since it saved a round trip and an empty call to the translation API.

Since Fluency is for translating and adding some nice-to-have things like the content change indicators on the tabs, maybe a secondary button off to the right to "Clear all content" would be useful? That could be a more intentional UI feature. What do you think? Worth doing?

[bernhard]

  On 3/28/2025 at 10:31 PM, FireWire said:

@bernhard I had a response typed out, didn't click "Submit Reply" and just came back find out that you never saw it 🤦‍♂️

Expand  

Yeah I was a bit surprised and almost already asking, but also was too busy with other stuff 🙂 

  On 3/28/2025 at 10:31 PM, FireWire said:

Since Fluency is for translating and adding some nice-to-have things like the content change indicators on the tabs, maybe a secondary button off to the right to "Clear all content" would be useful? That could be a more intentional UI feature. What do you think? Worth doing?

Expand  

That would be great! I was kind of expecting that it was intentional, but at the same time it is really a pain if you want to wipe content from a multilang field, especially if you have more languages (as you need several mouse actions for each language when all you want is to clear the field).

Also I can see that it might not be obvious to some that to clear the field in all languages one would have to clear the field in one language and then hit "translate to all". So I think an additional button would be a great ui improvement.

But I'm wondering... how would ProcessWire handle that without fluency. Wouldn't that either be a core improvement than an additional feature of Fluency?

[FireWire]

  On 3/28/2025 at 11:36 PM, bernhard said:

Wouldn't that either be a core improvement than an additional feature of Fluency?

Expand  

I do want to keep the scope of Fluency focused, but I'm comfortable with extending what it provides modestly. It would be a similar to how Fluency adds the content change indicators to tabs. It isn't something specific to translation functionality, but because Fluency provides the ability to do "mass translation" across multiple languages it's something that is helpful. I think that a "clear all" type of button is something in the same spirit. If Fluency can generate large amounts of content, it may be useful to have an extra tool to make working with it a little easier.

It's the "enhancement" part of the "translation enhancement suite for ProcessWire" 😎 ha!

I am weary of going too far beyond and making Fluency intrusive. Maybe adding it as a config option, off by default, to enable that can be helpful and stay out of people's way.

[bernhard]

  On 3/29/2025 at 1:09 AM, FireWire said:

I am weary of going too far beyond and making Fluency intrusive. Maybe adding it as a config option, off by default, to enable that can be helpful and stay out of people's way.

Expand  

How would a "clear all" button would be in the way of anybody? I really think that this is a must have feature. My client said so too. Would be interesting to hear other opinions, but for me I vote for enabled by default 🙂 

[Tiberium]

I got yesterday exact this question from a client.

He has 5 different languages. When he corrects one word, it is not very comfortable to update the other translations. Personal, I don't have a strong opinion if that has to be default or not. I have to go to the config screen of fluency anyway, to setup it.

 

[FireWire]

@bernhard I like your thinking 🤝

@Tiberium I'm glad you chimed in as well. Good to know that there are many people that will benefit from a new feature.

Here's the UI I'm working towards:

Going to create a new header action for translation related features. This will keep the UI tidy, clear all will be enabled by default, and doesn't need an option to enable/disable it on the module config page. @bernhard The icon to show the translator will be moved from the icon next to the translation button to the menu for consistency, since it's hover there won't be extra clicks.

It will of course politely ask you if you are sure you want to nuke all of the content...

I like this implementation because it will provide a good location for possible future features as well without crowding UI for fields. It will take a little bit to implement, I'm trying to keep up with work and I think I caught a bug with the custom header actions in PW core. I'll tag you both when it's on the dev branch so you can take it out for a test drive.