Jump to content

Fluency - The complete translation enhancement suite for ProcessWire


FireWire

Recommended Posts

On 11/14/2023 at 3:27 PM, FireWire said:

What version of ProFields are you running?

The latest: ProFields Table 0.2.5 on PW master 3.0.229

I did a minimal setup to try it out with one template containing:
- a Table field (1)
- a FieldsetPage field with Table (2)
- a Repeater field with Table (3)

On first try there is a js error when clicking on "Add new" but this can be fixed by editing the InputfieldTable.js file on line 193:

if(href && href.indexOf('#') === 0) { // check if href exists

(pinging @ryan so he can see this)

When adding a new row on (1) and (2), the Fluency button is there but is not responding to click. When creating a repeater item (3) and then adding a row there is no Fluency button.

Save the page and Fluency will now work on (1) and (2) on the saved row (still not on new ones) and (3) is not working at all.

Hope this helps!

 

  • Thanks 1
Link to comment
Share on other sites

@monollonom Big help!

This problem was caused by my replacing <button> elements with <a> tags for the translate triggers under fields. The fact that my links don't have an href="#" was an oversight because I always add those, but either way that would have caused an issue. I did that so that links could match any custom styles that were done to the admin, which was something that isn't possible if I used a <button> element.

I could revert to using a button, but it would be a welcome fix the JS could be patched with more specificity since the # href is very common. In any case, open to input from @ryan

In the meantime you can use the previous release as the only changes after this were for cosmetic reasons. Tables will work here: https://github.com/SkyLundy/Fluency/releases/tag/v0.9.0b

I've identified the culprit, my code wasn't accounting for hidden template elements that InputfieldTable uses to create new items. I haven't nested a table field in a repeater before, so I'd never have seen this coming. Working on a fix.

Thanks for the bug report and the assistance!

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...

Fluency has hit v1.0.1 and has been submitted to the modules directory, should be available pending review/approval. Really appreciate everyone's feedback and input to help on this project.

All new features from the development branch have been added to the latest release. This is a recommended upgrade for everyone that also fixes a couple of issues.

https://github.com/SkyLundy/Fluency/releases/latest

If you there are any bugs found during usage, please file an issue on Github where you'll get credit for your help, or consider creating a pull request with a fix!

@ryangorley That is most excellent to hear and I am very glad it helped! I've re-added a donation box on the module config page in the latest release, very appreciative of your support!

  • Like 4
Link to comment
Share on other sites

Got tagged by @monollonom over in this Weekly Update post. Dropped a new Fluency feature. One click translation for any module, core or otherwise. I translated all user-facing strings for Fluency itself to Slovak in 4 seconds.

173465105_Screenshotfrom2023-12-1220-38-24.thumb.png.aa4a6d249b0838be87d3a64f60d5b465.png

This may be useful for developers who need to get modules that end users will interact with in the admin localized much much faster. This uses a feature in Fluency where you can bulk translate a large group of texts to from one language to another at the same time.

Just for kicks I translated the entire ProcessWire core in under 30 minutes- that includes modules I don't even use. It would certainly need some proofreading, but the amount of work up front is significantly reduced.

Available on the dev branch.

  • Like 4
  • Thanks 2
Link to comment
Share on other sites

  • FireWire changed the title to Fluency - The complete translation enhancement suite for ProcessWire
  • 2 weeks later...

@FireWire I'm still loving the convenience of this module, thanks! I've got a couple questions:

  1. 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?
  2. 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!

  • Like 1
Link to comment
Share on other sites

On 1/9/2024 at 12:33 AM, ryangorley said:

@FireWire I'm still loving the convenience of this module, thanks! I've got a couple questions:

  1. 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?
  2. 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!

Welp, that second one is a weird one... I went out of my way to try and make sure that was handled- it works on the TinyMCE and CKEditor fields, didn't notice the other fields were affected. I'll have to chew on that for a minute since it's a relationship between JS and the browser's acknowledgement that something has changed. Searching for that specific info is harder than I thought it would be. If anyone has any info they'd like to throw out there on this, would surely appreciate it.

I misread this entirely and my code was at fault. Information on fix in reply below.

As for the first request, how about this?

dual_button.png.9a3da7f87d9cad6dd7c796fb2fac5bd8.png

dual_button_2.png.b08df1a47ccf576b9f48ae4e091d992d.png

Config page now has the option to choose "Both" for the translation action. Second button only shows up on non-default language tabs.

Download it on the Dev branch and let me know if that works for you!

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

New release candidate version pushed to Development branch. I'm confident that this is stable, but testing would be nice. @bernhard the fix for HTML entities in translations has been fixed, please test.

If you have experienced HTML entity issues in your translations and have translation caching enabled, you'll need to clear your translation cache to ensure that previous erroneous translations are removed.

Download here.

  • Like 3
Link to comment
Share on other sites

On 1/9/2024 at 12:33 AM, ryangorley said:

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?

I totally misread this. Fix is on the way.

Link to comment
Share on other sites

On 1/10/2024 at 12:07 AM, ryangorley said:

Hopefully someone here has a good idea for the second issue. [fingers crossed]

I've fixed that issue and pushed it to the development branch!

@bernhard Added the swap source/target languages feature you requested, along with some other updates to the translation tool!

fluency_swap_languages.thumb.png.b8d4a2599964e8f80f9d9b543e797038.png

I'm packing in a lot of updates to dev so the next release will be a big one. Want to get as many fixes and stuff into it before the version change.

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Fluency v1.0.7 is now available.

Recommended for all users. New features, bugfixes, and all of the features mentioned above are in this release:

  • Translation buttons can be switched between the original translate from the default language, translate to all languages (from any language), or both
  • Casting the result of a translation to a string or echoing it directly will output the first translated value (or only value if you are only translating one string)
  • Improvements to the standalone translation tool
  • Fixes a PHP 8.2 compatibility issue
  • Fixes translating content containing links to ProcessWire pages
  • Fixes an issue where API usage may be above normal in some instances (sorry)
  • Fixes translating page URLs when creating new pages
  • Early release Fluency API feature where you can translate any file, or multiple files, in site/ or wire/ in one method call. This will be updated with a new feature in the future, subject to change but useful now!
  • Bunch of other stuff that makes Fluency run better but you don't have to worry about

Big thanks to @bernhard and @ryangorley for their feedback and bug reports, release notes on Github credit their contributions!

  • Like 4
Link to comment
Share on other sites

Hi,
i'm running into an issue when working with repeater matrix (pro fields), which wasnt a problem using the "original" fluency. i didnt find a related issue, so i thought i might as well report as it also persists in 1.0.7 🙂

Textareas (body field) within a repeater matrix do not receive the controls for translating, whilst regular inputfields still do. The console log reads:

Uncaught TypeError: this.getEditorInstanceForLanguage(...) is undefined

here a screenshot of the interface; the error is thrown when the repeater matrix expand is triggered/the field initialized. textarea fields outside of a repeater matrix are fully functional as intended.

image.thumb.png.d5119f3c3bf77b7571886e85546de388.png

i wasnt really able to dig into it yet, as i will probably resort to the old version to get the site live, but let me know if i can be of any further assistance 🙂

  • Thanks 1
Link to comment
Share on other sites

@overoon Looks like a new bug to me.

So I was able to replicate this under specific conditions in both RepeaterMatrix and Repeater. For me this bug does not occur when:

  • A new item is added
  • The page is loaded with the repeater item containing a CKEditor instance is already open (not collapsed)

This bug does occur when:

  • A page is loaded with a repeater item containing a CKEditor that is collapsed, then clicking to expand (uncollapse) triggers the error.

Can you confirm that is what you're seeing?

Link to comment
Share on other sites

@overoon The bug as I described it above is addressed in the latest commit to the dev branch on Github. Please download and confirm this solves the issue!

Alternate temporary solution:

I was able to prevent this issue from happening by changing "Repeater dynamic loading (AJAX) in editor" to "New items only" in the settings for the field. This is a temporary fix while I work on this so you don't have to downgrade. Let me know if that helps.

1485913199_Screenshotfrom2024-01-2610-44-14.png.cd707a200dd57005f3851df00b1ec53b.png

Edited by FireWire
Added dev release link
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, FireWire said:

@overoon The bug as I described it above is addressed in the latest commit to the dev branch on Github. Please download and confirm this solves the issue!

Alternate temporary solution:

I was able to prevent this issue from happening by changing "Repeater dynamic loading (AJAX) in editor" to "New items only" in the settings for the field. This is a temporary fix while I work on this so you don't have to downgrade. Let me know if that helps.

1485913199_Screenshotfrom2024-01-2610-44-14.png.cd707a200dd57005f3851df00b1ec53b.png

Hi @FireWire and thanks for the blazingly fast reply!

I can confirm all of your findings and also: the fix on your dev branch resolves the issue 🙂

  • Like 2
Link to comment
Share on other sites

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?

  • Thanks 1
Link to comment
Share on other sites

13 hours ago, ryangorley said:

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.

Well I was certainly being presumptuous that people would be mapping everything to Fluency and didn't test for that scenario.

13 hours ago, ryangorley said:

Is that actually the problem, and is it something easily changed?

Actual problem. Easy or not, needs to be fixed. I'll come back and let you know when I've pushed an update!

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...