Jump to content

FireWire

Members
  • Content Count

    112
  • Joined

  • Last visited

  • Days Won

    2

FireWire last won the day on November 4 2020

FireWire had the most liked content!

Community Reputation

83 Excellent

About FireWire

  • Rank
    Sr. Member
  • Birthday January 1

Contact Methods

  • Website URL
    https://www.skylundy.io

Profile Information

  • Location
    California
  • Interests
    Web development & server stuffs.

Recent Profile Visitors

1,590 profile views
  1. Appreciate the consideration! I tried to make Fluency as modular as possible so hopefully it shouldn't be too hard to add another engine. If you take a look at how DeepL works with Fluency, it exists as it's own class and Fluency doesn't know how or what happens in DeepL, and vice versa. Following that structure, you could create a Lingvanex class that Fluency sends data to. Matching DeepL method parameters when calling it and data structures it returns could make it pretty straightforward. An idea I had would be to create a bootTranslationEngine() method that is called in ready() which would determine what engine/API key is available and instantiate the proper translator class in something like $this->translationEngine. That would replace $this->deepL in the Fluency module. I would make it a goal to abstract out any references to any brand of translator in the Fluency module's logic. As long as getClientBootData() and translate() take and return the same structure of data you wouldn't even need to touch the front end. I haven't really written any code that is collaborated on before so I hope that the commenting and overall structure makes sense. If you ever have any questions or want a shortcut to figuring something I did out then message me and we can chat.
  2. Really no problem at all. I've released a newer version since then that addresses an issue that I didn't see come up in testing previously. Just a courtesy tag in case the bugfixes end up helping someone. I haven't heard of Lingvanex before so I didn't know to look into them. Initially when I found DeepL I was really impressed by the service but needed someone else to really verify what was going on because I only speak English. I had a coworker who speaks Spanish look at the results and he was very impressed. I kind of stopped there and didn't think to look further. Overall if someone was able to verify the quality of translation of any translation then that's all that matters. I don't have any personal allegiance to DeepL, it's just what I found and what I heard about on the PW forums which also nudged me towards them. It would be interesting in the future to update Fluency to allow the dev to select a translation engine, and the way the module is built I think it could be done well. I wish I could work on that now but I just had 3 clients contact me for work and that's in addition to my day job...
  3. Important update to the module with a new release. Recommended that all users upgrade to the latest version The module has been updated with critical fixes and feature requests fulfilled. The module has been updated to fix an issue with lengthy content that would result in failure, mostly important for CKEditor fields that include markup in the content. This was due to the admin AJAX call to the module using a GET request where a POST request should have been used to prevent running into URL length issues. Translation was pulling from the wrong location in CKEditors so it was translating the last saved content, not the latest changes made in the field before page save. Use of Fluency is now permission based as requested. After upgrading all roles who should have access must have the fluency-translate permission added The configuration screen now has a new setting for the Preserve Formatting feature which addresses the issue reported in this thread where short strings or phrases were being returned with additional/missing punctuation. (internally this uses the preserve_formatting DeepL API parameter). It is recommended that this be enabled unless you have a specific reason not to use it. Public methods have been added to the Fluency module so that translation, usage stats, and available languages can be pulled from calling the Fluency module or by using the DeepL class directly. README has been updated with documentation for usage. A new parameter has been added to both the Fluency and DeepL translate methods that allow you to pass in any DeepL API key/values with your request. If you are currently calling either the module or DeepL class directly, please read the documentation as the parameters have changed. Return values from the Fluency module now match the return values from the DeepL module for consistency. This includes passing DeepL's HTTP response for use in programmatic conditions. The module has been moved from Gitlab to Github to adhere to ProcessWire's module directory requirements for future listing. As usual, more to follow! Latest: https://github.com/SkyLundy/Fluency-Translation/archive/main.zip Paging @adrian & @xportde & @bartelsmedia as you've been Fluency's alpha testers extraordinaire.
  4. That's interesting, I'd never actually tested that. I'll make a note to disable those translation connections in the module. Also really odd that capability doesn't exist... seems like literally the easiest translation they'd have to do haha.
  5. Pushed the fix that removed the bd() call. Thank you for the reminder. I put some work in over the weekend on the permission feature. The new permission is named "fluency-translate" in case you want to rename yours to match the later releases. This release also formally adds the 5th Fluency->translate() argument to feed in additional API parameters. Everything is always a time crunch between holidays here, looking forward to when I can get back to working on more changes. Permission will be the next feature. Excellent to hear that it's in production! We've been using it and it's been smooth sailing.
  6. Proper error handling is definitely on the implementation list. I guess it just got upgraded to a higher priority item now that we've seen that. For what it's worth I've been playing around with the API for months and haven't experienced that. Not downplaying the importance of error handling, just hoping that means they're correct when they say that it happens seldomly. I'll be pushing more work when I can get some time dedicated to the module. I'm slammed at work right now but I will prioritize error handling when I'm back on the project. Thank you for reporting this here as someone might look for answers if this happens again, even with error handling.
  7. Ah yes, that is a very good point given that there is a cost factor. I will add a dedicated permission in the next versioned release. Thank you for the feedback!
  8. Heck. I'm just going to modify the module so that all (or as many as possible) API parameters can be accessed/configured in the module. The developer should have as much control as possible.
  9. I fixed that missing semicolon and made the translate method public and pushed it to dev- excellent feedback. Apologies for the missed semicolon and wrong parameter explanation. I was coding and pushing without testing since I wasn't able to do that at the moment. My goal is to make the Fluency->translate() method a more refined way to call the DeepL API. For instance, if you use the Fluency->translate() method, it will always account for the settings made in the module's PW config screen whereas a direct DeepL->translate() call won't. There could be advantages to using either depending on your use case, but the methods will also always take the same arguments so that either can be used interchangeably and predictably. And- as you noted, calling the Fluency->translate() method requires no manual API key insertion. I personally don't like having to stuff empty arguments into a method call, like how you had to provide an empty "[]" array before adding the config argument. The ignored strings array may be something I merge into the config parameter. It makes sense to me since if you're calling the Fluency->translate() method and have ignored strings configured then you might be passing an empty array more often than not, or the DeepL->translate() method and do not require ignored strings. This may be a breaking change coming up, so I'll post back here when that gets pushed to master. I want to do some more research on the preserve_formatting parameter and consider if it should be set to true by default. Since we're working with CMS input there should be a level of expectation that the translation service does not try to correct the user but rather deliver a more direct translation which would prevent the situation you saw. Overall, if there's anything set by default in the module I want to add a config screen toggle for it so that the developer can make the ultimate choice and be able to control how the module works.
  10. @adrian I just pushed an update to the dev branch. It adds a 4th parameter to the translate() method in both Fluency and DeepL classes. You can pass a key/value with any additional DeepL API parameters to experiment with. There's a DeepL API parameter called preserve_formatting, and by default it is off- so it will try to correct punctuation. Try the dev branch and update your call with this then pass it the string that was giving you problems and see if it helps: That should tell DeepL to stop trying to correct you. Let me know if that does anything for you.
  11. Yep. That's a proper syntax to make a call. The text string for translating can also be an array of strings (either/or) which will be returned in the same order as you submitted, good for bulk translation. The DeepL class is and will be wrapper for the DeepL API so it should be as predictable as using it directly. The added period is not something I've seen during my usage so unfortunately I don't have experience. We've been translating one and two word strings, such as text for buttons, and they've never come back with any additional punctuation. The API has additional parameters which seem to be much more granular but I wanted to see how basic translation works out for PW implementation and then add additional features as necessary rather than fully integrating the API with things that would go unused. Also, since you're calling the API directly, you can wrap text to be ignored like this: <fluency-ignore>Don't translate me!</fluency-ignore> That's what's used in the DeepL class to ignore strings configured in PW. If you add them yourself the DeepL class will remove them automatically after translation.
  12. These are stellar ideas. I can add the hanna code exclusion as a config screen setting. I'll put that on the roadmap. The regex idea is also great. I think adding them both will keep it flexible and friendly (regex... not always friendly haha) Really glad you are enjoying the module. I want to get more feedback from people using it in production before pushing it out of alpha and adding it to the modules directory so when you get a chance to use it more I welcome your feedback and any bugs you come across. We're using it production for a website launching on Friday and it's done well for us but more data is always better!
  13. Oh now I get it. I misunderstood when you said you installed from a URL. I don't make use of that (for some reason, habit?) so I've never run into that before and it didn't hit me. I'll restructure the repo and push that out. Thanks for the heads up. edit: Doneski. Repo has been updated.
  14. I'm not able to replicate this on my end- just to clarify, are you getting two nested Fluency directories in the .zip file? I haven't seen that before.
  15. Interesting, I haven't seen that on my side but will update!
×
×
  • Create New...