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!