FireWire

Hahaha- those are great. This is what I'm putting on the invoice line item. That's it. Also, new DJ name.

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

Don't be fooled! This reporter has published propaganda to make people think that strategic and intelligent thinking will lead to a successful WordPress update. In reality, there is no logic or reason that can prevent disaster, you are at the mercy of chaos and a hateful god determined to destroy your will to live. To describe this in more depth, one of the plugins simply wasn't able to be downloaded without paying for another license which prevented the entire site moving from PHP 7.3 to 8.1. There was another plugin for forms that showed a "This form is temporarily unavailable." error to website visitors. This plugin author has decided that not only will it stop working- it will break your site's functionality. After running a standard plugin update in the WordPress admin- it removed functionality and demanded additional payment. The plugin did not indicate that a new license would be needed before updating, and thanks to caching- you couldn't tell the form was broken on the front end! Also- let's talk about caching! Caching for WordPress is a complete mess. Sure this is not exclusive to WP, but it takes the cake. Why? Because hosting companies' "Managed WordPress" plans which are an attractive option for hosting companies because it lets them set very aggressive caching policies to squeeze more capacity out of cheap crappy shared servers. This is why "Managed WordPress" hosting is almost always run on shared servers- even WPEngine, one of the more well known and much more expensive services, is all run on shared servers. I confirmed this via their sales team who was harassing a client about their website's monthly traffic limit. They said that the overages cause "performance issues". After confirming the server isn't a VPS (although they price it like it is), I asked if "we should be worried about other sites slowing down our site because WPEngine uses shared hosting". They left the client alone after that. WP is frustrating, but I take a deep breath and think about how that WP money is helping pay for an upcoming vacation. So... thanks WP?

Oh, what's this? Another completely different site borked itself? Performed an update using an automated tool through the web host where the core and all plugins are updated at the same time. Is there a right way to update WordPress? The world may never know... This update has has rendered the Admin unusable and inaccessible. Time for a server rollback! Okay! We're back... oh boy... Did you know? Deactivating plugins in the wrong order can make the plugins page hang on a redirect loop every time you try and access it. Time for a server rollback! (Before someone says "that was a caching issue", no it wasn't) Okay! We're back... oh boy... Did you know? In WordPress, a commercial theme or plugin you've purchased and installed may install other commercial plugins that require their own license. When that license expires, you may have to pay for a separate license for the plugin that the plugin/theme you already purchased installed when it comes time to upgrade. PROTIP: the commercial plugins that were installed by the theme or plugin you purchased are not easily recognized as a dependency or indicate what plugin/theme installed it- so, when working on WordPress, keep a shovel handy in case you have to start digging!

Oh heck. Gotcha. I just remembered I hadn't pushed all of the new features to main- so you can ignore that. I'll take a look asap. What version of ProFields are you running?

Okay- I'll take a look. Unfortunately I am completely overloaded with work right now so the fix may be a little delayed. Can you switch between the button styles (translate from default vs. translate to all) and see if there's any difference? Really appreciate the help!

This is an oversight on my part- if the field is empty, it shouldn't translate. Problem solved. The following two issues are solved by a translate to all button on non-default languages, and the translation button type is still an option on the module config page ? The real point for a "translate to all" button is to make it easier for the end user and to prevent content deviation, where one language says one thing and another language says another. It's very easy for an end user to forget to translate content- so there is no translated content, or the translated content becomes out-of-date. I've seen both of these issues in sites I've built that had people doing SEO work, or just managing content in general. The "Translate to all languages" and the content change indicators are the best way that I can think of to help people enter content, click translate, and complete their work with the highest amount of accuracy. In my experience non-web people aren't as engrossed in the process of maintaining websites as much as developers are, so unless you make it as simple as possible it increases the likelihood that the website will be poorly maintained. Also just realized that the new "Translate to all languages" button doesn't work when translating the page's URLs. Will push a fix for that.

Bonus! I've added an option to enable "Translate to all languages" for each Inputfield ? Enable the new translation button on the module config page. The old style of translation (translating each language from the default language) is still available for those who want to use it. Translate to all languages at once from the default language Translate to all languages at once from any language. This is where the tab indicators come in really handy to indicate the tabs that have received updated/translated content with one click. This is on the dev branch as well, so give it a try and tell me what you think.

Links to ProcessWire pages in translated content now point to the localized URL. I'm pretty sure this is good to merge into a release, but extra testing would be the best idea. @bernhard Pushed to dev branch https://github.com/SkyLundy/Fluency/tree/development @jacmaes I saw that like on @bernhard's post if you want to take this for a spin as well.

Impressive. I was thinking about some of the higher latency I've seen in databases that aren't located on the same server that is hosting ProcessWire. I'm sure it will be fine. I'm sure someone will come back and let me know if it's too slow ? Started working on this but have been super busy with work. Will report back here when the release is ready.

Completely agree, glad you brought this up. Working on this now. I might have you take a look at what I put together on the dev branch to get your opinion. I wanted to give it a shot since it presents a few challenges that I'd like to try solving, one of which is this: <?php ProcessWire\PageFinderSyntaxException OR values not supported for multi-language 'path' or 'url' at wire/core/PageFinder.php:3684 3680▕ * @throws PageFinderSyntaxException 3681▕ * 3682▕ */ 3683▕ public function syntaxError($message) { ➜3684▕ throw new PageFinderSyntaxException($message); 3685▕ } 3686▕ } 3688▕ /** Trying to keep this efficient so if there's 5 (or many more) links in a translated text, then it would be preferable to make one $pages->find('{selector}') call rather than looping over them and making multiple calls. Do you think this can be done in one? Will this need a raw SQL query (if that would present a solution)? I think another downside to multiple calls would be that this is querying the "name" column which isn't a MySQL indexed column, so a site with many many pages might experience additional slower performance. The only thing we have to work with in the <a> elements is the href value... Whoa there cowboy, we're really stacking up new features here and I can't keep up ?

This is a great case for including a "Translate to All Languages" button on all language tabs! I didn't think about that. This is a great real-world example. I'll add that to the roadmap. Very awesome to see that feature solve an immediate need!

Last time it did, but I guess not being a complete failure this time is something to celebrate. Kudos to WordPress for doing the bare minimum! Here's a gold star ⭐

Translate to all languages is on the roadmap. Very desirable feature but a lot of new code separate from the existing buttons/translating UI/error handling. I have an implementation in mind but didn't want it to hold up releasing the module, especially since it was so long overdue. I know this can be really annoying and I want to have this feature implemented as well. I had plans for a "Translate to All Languages" but not buttons for individual languages since it could lead to content that doesn't match between languages. Also want to keep it dead simple for the end user. Open to thoughts on this. I think that the way that tabs show that content has been modified is a good way to know that the content for another language has been updated. Some thoughts about switching to a tab after translation: The person translating the content likely doesn't know how to speak the language they are translating to If they need to go back and edit the content again there's an extra click to get back to the language they do speak The change indicators on the tabs are bound to the state of the Inputfield independent of the translation function, so you can trust that the content has been translated When the "Translate to All Languages" button is implemented, all of the tabs will show that they have been updated so it will be easy to see The flip is a great idea. I left that second select open since it's a "global" translator that provides all of the languages. I don't have any issues with it being pre-selected. Are there instances where you need to use the translator tool rather than on the fields themselves?

@everyone (how annoying would it be if that actually worked...) If you've got a Github account and want to support ProcessWire and the community, why not go give this icon PR a ?? Great way to show the icon repo maintainers that there are people out there who love the platform. https://github.com/devicons/devicon/pull/1905 And while you're at it, go give the ProcessWire repo a ⭐ as well! https://github.com/processwire/processwire

Here's a Google Maps WordPress plugin that takes advantage of needing a Google Maps Platform API key. They redirect the user to this page to promote their $12/mo. paid plan even though Google will charge you $0. They're happy to charge you up to $109/mo. for 10,000 views even though Google's platform affords 26,000 under their monthly free credits. Stay classy.

@bernhard Fixed. https://github.com/SkyLundy/Fluency/releases

Release 0.9.0b is up. This solves the global excluded strings issue, also updated to work with DeepL's new documented method. The excluded strings field now uses a || (double pipe) separator rather than a comma since a comma is punctuation that could be present in an excluded string. This also has two features suggested by @bernhard. The icon next to the translate button under fields is now a button itself that opens up the translation tool. The translate button itself is now styled by the admin theme as a link so changes to the admin colors will carry over. https://github.com/SkyLundy/Fluency/releases/tag/v0.9.0b

Nope. I have a fix coming today, this is a bug. I'll add another comment here when it's ready!

@ryangorley This is helpful and I'll try to replicate this. Have you added anything into the "Global Non-Translated Strings" field on the module config page? What are your settings for "Preserve Formatting" and "Formality"? I was able to replicate this by adding some excluded strings in the module config, let me know if this happened without your having added any. Fluency is compatible up through 8.2, I held off on using some 8.2 features to keep it compatible with more installs and the rest of the code is up to date, this is an isolated bug. So go with 8.2!

Hey @wbmnfktr, now we wait... https://github.com/devicons/devicon/pull/1905

Welcome to ProcessWire! Hope your experience has been great thus far (well, aside from this error you're seeing) and thank you for the kind words. 1. Absolutely will be adding it to the modules directory. I'd like to get a couple of tweaks in and iron out any bugs that may pop up, I have done as much testing as I can on my own and I need to make sure that "it works for me" means "it works for everyone" haha. @bernhard had a great suggestion for using hooks. As soon as it's had a little bit of usage I think it will be ready for the modules directory, so your feedback and bug reports are very helpful. 2. Translation engine requests are logged, so check the 'fluency-engine' log. That should help figure more out. If that isn't helpful then try using the network tab under your browser development tools, try translating something, then check the JSON response. Another question- does the translation tool accessed by the menu at the top of the page work? I too have had some secondhand experience with the challenges of adding multi-language capabilities to WordPress. My partner manages a WP site for the company they works for and had to try several plugins, some worked partially, all were difficult to use. Fluency was designed to be better than anything WP has available and those problems guided my work. Feel free to share your story over in this forum post celebrating WordPress.

Clients should always have their own accounts! If a features that a client wants or needs that need a 3rd party service, I present the information to the client, explain the pricing, and let them know that the account will be a service that they subscribe to. I like to emphasize that this means that they have ownership of the service and don't have someone in the middle (like me) charging a premium as a reseller. An example besides DeepL is a service called Smarty, which is an API to work with addresses. I am doing work with a client's CRM and explained that their address data isn't high quality enough to complete the work they need. I told them there's a free 30 day trial, and after that it's $54/mo. It sounds steep, but the client understood that it was an important necessity. It's a cost of doing business for them, just like DeepL may be. There are two sets of pricing for DeepL, the price to use their application, and the price to use their API. There are 2 separate pages for subscription plans, and on the "Plans and pricing" page it has both subscription types. It can be confusing due to how they have it presented. Here's where they have that hidden: I looked at the pricing plans and I don't see anything that would prevent a client from using the Free plan, unless 500,000 characters isn't enough. Then it would be €5.49 to sign up for the Pro plan, and then €20.00 for an additional 1,000,000 characters. So 1.5 million characters for €25.49. If it really came to that I would think that in most cases it would be possible to sign up for one month of Pro to translate the initial large amount of content, and then downgrade to the Free plan with 500,000 characters- unless they're publishing a ton of content per month! In Fluency you can switch between Free and Pro accounts without any issues or additional configurations needing to be made. Hope that helps, but if not let me know.

I was going to create a PR but can you give these a second set of eyes first? Specifically the "processwire-original-wordmark.svg" file. The SVG here on the PW website uses transparency, but in lieu of that I used an equivalent color so that no transparency had to be used in the SVG file itself. processwire_devicon.zip

Well here's a big announcement. The full rewrite is done. I bet you thought I forgot about this project, but nothing could be further from the truth... This is a complete rewrite of Fluency and it has a lot of new features- including a big one I said wouldn't be ready... it's now possible to use other translation services besides DeepL. Currently only two are available, DeepL and Google Cloud Translation. However- Fluency now includes a complete framework for creating "Translation Engines" that power fluency. I'm working on documentation and contributions in the future are welcome! There are a lot of features that have been added. Some I mentioned above, but they're here too. Ability to add new translation API services and a framework for developing them Language tabs now have indicators to show where content has been changed since page load. This makes it easier to see if some languages have not been converted Per-engine configurations. The Fluency module config page will dynamically show you the configurations that are needed for each engine. Translation engines retain their own configurations. It is possible to switch between engines with very little work. Full support for all ProcessWire fields, including TinyMCE. Both TinyMCE and CKEditor inline modes are now supported as well Polite and informative error handling Full UI translation for all Fluency components. Errors, buttons, labels, everything in Fluency itself can be translated and therefore customized. Full caching for translations and language lists. Caching can be cleared on demand. DeepL now has full support for translation features, including formality The module config is much nicer Meta tags for alternate languages can be rendered for the <head> element A language select dropdown can be rendered that reloads the page in a selected language You can easily get the language ISO code as well There's more, I'm probably forgetting some stuff. Check the module code. If you want to see what an overengineered ProcessWire module looks like, check the code. Check the methods in Fluency.module.php. Fluency is now globally accessible using the $fluency variable if anyone uses it. The admin REST API is completely documented as well. I'll be following up with more documentation on building Translation Engines, but it's already started and located in the module's subdirectories. Oh- and all documentation within the module is fully formatted and compatible with the outstanding ProDevTools module API Explorer. I've come to love that tool so I made my module work with it as well. I put all of the markup features I mentioned adding in a Pro module into this one. I'm not going to build a Pro module, all future features are going into this one. So it's all free now and forever. https://github.com/SkyLundy/Fluency Let me know what you think and about any bugs found. Also interested in hearing what other translation services you are interested in, and if there's any interest in someone helping out with building new Translation Engines!