Jump to content

FireWire

Members
 View Profile  See their activity

  • Posts

    475

  • Joined

  • Last visited

  • Days Won

    31

 Content Type 

Everything posted by FireWire

  1. FireWire
    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!
  2. FireWire
    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.
  3. FireWire
    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.
  4. FireWire
    @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.
  5. FireWire
    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.
  6. FireWire
    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!
  7. FireWire
    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.
  8. FireWire
    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.
  9. FireWire
    Interesting, I haven't seen that on my side but will update!
  10. FireWire
    Okay- I did misread that a bit. I will admit that my .htaccess-fu is a bit lacking when it comes to more effective redirects and I'm in a timeline-bind. Should have gotten started on that sooner... Thanks again for this info. Surely will come in handy in the future!
  11. FireWire
    Just want to spell out the solution to save any devs who see this post a little time and jump to the solution. As mentioned Jumplinks does not yet support multilanguage URLs. Trying to redirect "naturally" using Jumplinks will have your multilanguage page redirect to the page in the default language. You will have to create a Jumplink redirect for every language on a page (sorry big site and big language devs). Here's a quick screenshot with some explanations: Here's the gist- create your default language redirects as usual using Jumplinks as designed. For your URLs in other languages, add your source language URL as normal, but when entering the redirect destination, manually add the proper language URL and add the ? to the end of it. This "tricks" Jumplinks and creates a kind of sticky URL which Jumplinks won't replace with the default language URL. Couple of pro-tips after working through this: On your source URL, I highly recommend adding the [/] to the end of your source URLs. This makes the redirect work with URLs that end in a trailing slash and those that don't. Regardless of your chosen configuration for URLs it is always a good idea to account for possible user edge cases. Keep SEO in mind! Ensure that your destination pages have a meta canonical URL tag. Google is very literal when parsing URLs and by adding the ? to your destination page you run the risk of fragmenting your content into 2 URLs. Without your canonical tag, Google may index them separately and it is possible that your pages will compete with each other in search results and possibly replace your nice URL with the URL you appended ? As always, test, test, test. Just wanted to provide a shortcut to the solution in the Jumplinks thread. Happy redirecting!
  12. FireWire
    That's my conclusion as well. I didn't want to tinker with ProcessWire's internal workings so I left that redirect parameter alone. Also can confirm empirically that placing my redirect rules didn't stop Apache from parsing the document after the redirect, which while frustrating kind of makes sense given the gravity of important configurations contained in the file. And I agree about complexifying (new word) htaccess too much. Many thanks for the additional insights.
  13. FireWire
    That solution worked like a charm! Thank you for the compliment on the site. Looking forward to launching it on Friday!
  14. FireWire
    Thanks for that link, I skimmed the pages but there are a few in that post haha. I'm still curious about the it parameter though, any insight on why it exists or what ProcessWire does with it?
  15. FireWire
    I did but it's a multi-language site and from what I understand that module doesn't support that unfortunately.
  16. FireWire
    We're launching a new version of our website and I need to create redirects from old pages to their new counterparts at different URLs. An example rule that I've created is Redirect 301 /solar-energy-for-business /solar-energy/commercial-solar/ However when I visit the redirected URL it shows up in the address bar as: https://staging.renovaenergy.com/solar-energy/commercial-solar/?it=solar-energy-for-business We're creating these redirects for SEO purposes and they need to not have additional URL parameters being added. This line in the .htaccess file is adding the original URL as a parameter. RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] Does ProcessWire use this parameter for a purpose? What is the best way to create these redirects without this parameter?
  17. FireWire
    This has been fixed, the translation tool can be accessed by anyone with page-edit permissions, which was the original intent of the module. Out of curiosity- do you see a need to break down access to the translator tool to a specific permission? I'm curious about that idea but didn't think there was a use case. New version is 0.2.2 - quick link to download the latest: https://gitlab.com/SkyLundy/fluency-processwire/-/archive/master/fluency-processwire-master.zip
  18. FireWire
    Oh I have never really used CKEditor fields in anything other than regular mode. I will update the description of the module with that information and add that to the roadmap. I added a permission to the implementation at the company I work for. I will add that to this module as well. Update should be pushed soon and I'll let you know when that is available
  19. FireWire
    Just found out from a user that the browser plugin for Grammarly conflicts with Fluency and causes errors which prevent translations from working. Grammarly is known to cause issues with some web apps and the company seems to not be interested in working on compatibility (as an example, Grammarly has ignored requests to fix conflicts with WordPress' Gutenberg interface for years). Considering how prevalent these issues are with many sites, this isn't a priority for the module's development. Just a heads up in case this becomes an issue for you or your clients. If you have any insight on this that could help solve the issue please open a ticket on the Fluency Gitlab repo.
  20. FireWire
    Unfortunately I haven't localized the UI yet but that is the next priority item on my list. If you have your primary language set as German and the other language as English, the translation link will still say "Translate from English" but it will still translate from German to English. Right now this issue is purely aesthetic. Here's the language translating from German to English but the translate link saying the wrong text. If you would like to change these now so you don't have to wait for a module upgrade, you can update the text strings located on the following lines in these JS files: Fluency/src/js/fluency.js 153 160 216 473 476 490 Fluency/src/js/fluency_language_translator.js 108 168 By changing the text there the module will then fit your setup. Like I mentioned above, I'm working on having this behave correctly out of the box!
  21. FireWire
    Just doing it for the love of the code. Really striving not to "lock in" hard definitions into the code like formality. A workaround I am thinking about is adding an ability for a developer to configure language/formality association with directions for them to review the API as a step to make it work. Believe it or not, I sent a request to DeepL to see if they have a way to query formality that isn't documented The module is essentially a DeepL API wrapper with a lot of the work being handled by the front-end JS. The module itself is going to go through some evolution before I can push it out for collaboration. I'll add a module method to work with files. I still need to firm up the structure of the data returned from the module's methods and then document it. It would be awesome to see this integrated in with your EditorJS module which looks super awesome! I've got a separate repository for a CKEditor integration that I could use a help with. I set that up over the weekend but haven't really touched it. Just did some skeleton code to add the ability to highlight text and exclude it from translation but it's not even close to useful. PM me and let me know what you think.
  22. FireWire
    Everything is hackable... That would interfere with ProcessWire's existing UI where clicking on a tab that is already selected changes all of the tabs on the page to that language. I don't want the module to alter the native PW interface and take away a feature. I may revisit the idea of translating a field to all languages at once and test it out to see if it is feasible in practice. If I can do that while being able to provide a progress bar or something then I think that would be the way to go. That would take care of the amount of work of clicking for each language, save space, reduce scrolling, etc.
  23. FireWire
    Yes, that is a limitation in the on-page UI. Initial goal is to keep it simple for the user to translate from the primary language with a one click operation rather than needing a select input to choose the source language. I prioritized the translation tool in the menu at the top is to translate content from any language to any language just in case that becomes something that is needed. That was the goal of making the link a modal so that tool can be used anywhere there has to be content translated from any language to any language without leaving the page or tab-hopping. I had the same thought but was concerned about having it stack up against the language tabs if there were too many of them or if the screen was smaller (like in the screenshots in the original post). I could try experimenting with the translation trigger placement in the future but it would be sometime after localizing the UI so more people can use the module.
  24. FireWire
    I'm continuing work on this module as it gets more time in use and any edge case issues pop up. I'm going to be working on fast iterations while in alpha to address problems quickly so the module can get to a formal release. If you download and test/use the module please submit any issues via the Gitlab repo so it's on my radar. Be sure to check for newer versions on the master branch to get the latest stable version. The next push to master will contain a changelog so early users can track changes and decide if a module upgrade is needed. Thanks again to those who are able to help! Here's the link to the repo: https://gitlab.com/SkyLundy/fluency-processwire
  25. FireWire
    That's excellent to hear! Glad it came in time. I'm going to be launching a site that uses it in the next few weeks as it is stable and useful right now. It should have more features and time in production by the time you use it! If you get any time to play around with it or use it in the meantime I would love to hear feedback and any bugs you find. Cheers!
×
×
  • Create New...