FireWire

@update AG Great to hear! I changed how Fluency stored config data. The issue you experienced helped find an edge case where the module may cause issues for some people. Your issue where you experienced two translator pages has also been fixed as well. Appreciate the feedback and helping make the module better. I'm going to add this to the next release but will try to see if I can prevent any need to uninstall/reinstall and preserve settings when upgrading.

Impressive and awesome module! Nice work!

Hey @update AG I've pushed a revision to the module that changes how configuration information is stored in the database and removed all serialization. It's on a separate branch so that you can test it. This requires that any Translation Engine related data will need to be re-configured. Please download and test from this branch on the Fluency repository.

These sites are outstanding! Fantastic work and couldn't agree more with your feelings on ProcessWire. Thanks for the mention as well, it's really cool to see Fluency out in the wild!

Thank you for double checking. I've seen a lot of different mod_security implementations (have done it myself) and there can be a lot of variance. I had one host change the error response to HTTP 418 I'm A Teapot (very unhelpful...) and others return other 4xx codes, but haven't seen a 503 Service Unavailable because that indicates a server failure, not an issue with the request. That's not to say that your hosting provider hasn't chosen a 5xx status and has a really strict implementation. Alas, I'll work on updating how the module stores information and push to a separate branch so you can test and see how it works in your environment. I'm putting out a few fires today (anyone else having to deal with DMARC records?) but I'll get to that as soon as I can spare the time.

This path is only for use by AJAX to make the translation request, so accessing that URL directly won't work. Can you open the developer tools and go to the Network tab, try to translate something and then show me what the response body is?

This is interesting and I hadn't thought of that before. I'm no expert on DeepL's internal logic, but I'd venture to guess that this "passthrough" is also what prevents it from trying to translate things like proper nouns or selections that it can't translate with confidence in accuracy. Double edged sword I guess. Edge case- the page title could be "Take The Next Step" but the slug in English is "/contact-us/" so the translation to German would be "/de/den-nachsten-schritt-tun/" which doesn't match. It becomes more complicated when someone renames the page to "Find Out More", so the German slug is orphaned entirely. I'm not sure how prevalent that would be, but it draws a connection between page title and URL where they serve different roles. I haven't seen this situation myself so I don't have anything to go off of or know if this is a big ask- is it possible to tweak the default language URL so that it has more parity across languages? This is a very interesting situation and one that I haven't heard come up or experienced myself. I am at a bit of a disadvantage because I haven't used Fluency in production since I released the rewritten module last year and that DB serialization was only introduced then. Do you have access to any logs where you could verify a mod_security issue? Is there anything in the response headers of the 503 page that could help? I can modify the the module but would like to be sure that it's not a different problem that may need to be addressed.

@ryangorley fix pushed to the development branch. Let me know if that doesn't solve it!

Well I was certainly being presumptuous that people would be mapping everything to Fluency and didn't test for that scenario. Actual problem. Easy or not, needs to be fixed. I'll come back and let you know when I've pushed an update!

I'm coming back here to say that RockPageBuilder has made me a convert. It addresses every concern I've ever had with page builders, fully stop. On top of that, provides powerful modularity that can help speed up future projects. Worth every penny. Outstanding job by @bernhard

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

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

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!

Just sharing the struggle, I am so tired of typing this word.

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

I totally misread this. Fix is on the way.

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.

I will wholeheartedly admit that I may be going a little hard on WP. I know there are good devs everywhere who use the platform that works for them and their clients. I could be taking it a little easier on WP and it's plugins. ALRIGHT, THAT HAVING BEEN SAID *takes swig of beer, chucks bottle* Kidding, but I have been posting very punctuated examples of issues, some of which are more widespread than others. I also haven't been posting any real nuance, so I guess that's also not really a fair play either. I'll admit that I haven't been in a situation personally where a media manager came to mind- so I'm not going to make a blanket "never use them" statement. I can definitely see how what you said could grow into an issue, and combined with the "free for all" no size limit image fields, certainly. I like per-page media but a centralized media manager makes sense logically, especially to developers because we reuse code/resources to stay DRY. It's 100% appealing to me in that sense. However the "management" part of a "media manager" takes active effort and I'm inclined to believe that this isn't something clients/users keep in mind. I say that both theoretically and empirically. Media management can be an efficiency construct that exists outside of "keeping my website updated". Contrast to PW's per-page assets that works the way a client would think it does- when a page doesn't exist anymore, none of it exists anymore. The developer gives up what they know would be a better idea technically for asset reuse (central management) for the simplicity in user experience (distributed management). Recently I was forwarded email from a client from their web host stating that they had reached their website backup space and directed them to upgrade their plan. They asked if they should buy the upgraded package, I told them I'll take a look. I logged into one of their WordPress sites and deleted almost 1gb of images that had not been in use for years. Logged into another and deleted even more. I was almost 100% sure I knew what the culprit was just reading the email. This was a layer deeper than their server disk space. A hybrid approach (I'm sure this has been discussed before elsewhere already) in PW would be interesting where asset fields have a "Select From Another Page" option that allows for reuse, but is still tied to pages. Not to get too in-the-weeds, but extend the current assets/{page id} concept where selecting an asset from another page moves that file to assets/{new id}_shared. Now both reference the same file "manager style" on the filesystem. Asset fields could have a way to view a list of pages that also use the asset, with the ability to "Delete From All". If the file is removed from all pages except one, it's moved back to the assets folder of that page and assets/{new_id}_shared is deleted. The back end handles the centralization, the user's workflow remains enhanced but without additional work. One of the things I discuss with clients is "How can we add utility without increasing workload?". It helps us balance what they want with what they can or are willing to do to make it work. I'm inspired by Colin Chapman, founder of the Lotus car company, where his philosophy when building cars was "Subtract weight, add lightness". In day to day use, I think an optimization for the developer should feel like an optimization/feature for the user if they have to interact with it (as much as reasonably possible of course). I will repeat the caveat that I haven't experienced a situation where the solution was centralized media management- or I've been such a devotee to distributed management that I never think to consider it. Either way that's on me ? The only time I've run into this is for truly site-wide content like logos, or certification/awards logos for the footer which is handled easy by a "Site Settings" page in the page tree, it works because there's still some sort of dedicated purpose for those fields that keeps the images contextually organized. That might be another case-in-point about my limited experience in that situation though. I considered this the most on the my last post re: Contact Form 7. It's a plugin and not core, absolutely. So the developer dropped the ball, happens. Unfortunately issues happen all too often, so I mention it in a manner of a cumulative stack amongst many plugins. I will suggest some responsibility by WP though because of it's built-in reliance on plugins- oh, you want custom fields? (you know what comes next) It's arguable that there's an ecosystem problem, one that WP's architecture, theme reliance, messy admin, and plugin implementation has a healthy hand in. Is the complexity or quality of the core a contributor to plugin problems? 5 minutes with the WP Codex is a little convincing IMHO. If I had the time maybe I'd try my hand at Fluency for WP (did I just say that out loud?). Ironically, the list of issues I (and many of us) could come up with exists as an antithesis to the PW methodology- and I guess that's why we're all here in the first place. So I may need to acknowledge that the dead horse is dead and put my beating stick down ?

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

@neophron I've noticed that WP sites tend to be big, if not massive when it comes to file/directory sizes. You're right about the auto-generated code as well. I think that WP's central media library lends itself to massive amounts of unused images because they are uploaded and then associated with pages, the opposite of what PW does by associating images at time of upload. It requires a lot of manual maintenance. I'd rather a user replicate an upload on multiple pages than rely on a central media manager that requires manual deletion when an image isn't needed anymore. A user won't do it, and shouldn't have to. Now we can all agree why hosting companies love WordPress. They love selling people more GBs of disk because they run out of space on their server...

Upgrading plugins? Contact Form 7 changed IDs in their shortcodes for embedding forms from incrementing integers to hash based strings. From the release notes: orly. You see- upgrading the plugin replaced all of the IDs for the forms. It didn't add hashing, it replaced all of the integer IDs in the database during the plugin update process. Instant borkification. I've dipped my toes in programming once or twice and I can tell you that seems like a pretty big oversight... TO THE GOOGLES! First result was a support thread for this issue on the plugin's website. Hey- marked resolved, day has been saved! But there's no actual solution in the thread. IT WAS A RUSE. So here we are. Just in case anyone using WordPress needing help on Contact Form 7 is still looking for a solution and stumbles on this thread, I'll provide it here on a different CMS' support forums: Go through your entire site and replace all of the existing shortcodes for all of the forms wherever they were added on pages and templates with the new ones. By hand. Couldn't be easier. The mostest popularest user-friendliest CMS strikes again.

Fluency has been added to the ProcessWire modules directory! https://processwire.com/modules/fluency/ The readme and module documentation has been expanded significantly to document all of the features available to you when using Fluency, including markup rendering. Enjoy!

Can you share what platform(s) you use as an alternate to ProcessWire in these instances? As the developer of a language module maybe there is some inspiration to be had.

Well, since @monollonom tagged me I thought I'd tinker. I added a one-click button to Fluency that translates any module file, core or otherwise, in seconds. It's integrated with the native ProcessWire language translator pages. Some details here. It makes it entirely possible for everything a user interacts with in the admin to be translated within minutes, not hours. I didn't know about this module... this looks great! Language is a tough nut to crack and applying a universal solutions are difficult. It's huge task for a module developer, contributor, or a core maintainer like Ryan, to take on when they are providing free and open source software for the community. The fact that ProcessWire handles language so well to begin with shows a thoughtful approach by Ryan and ProcessWire contributors, especially if it is as rarely as you assume. Try Fluency and let me know if it helps out.

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. 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.