search

SkyLundy / Fluency-Translation

A DeepL translation integration for the ProcessWire CMF/CMS platform
GNU General Public License v3.0
11 stars 1 forks source link

Handling js/xhr errors #6

Open ivangretsky opened 3 years ago

ivangretsky commented 3 years ago

Hey, @SkyLundy !

I had some non-reproducible bug. The module config on one installation was kind of broken, I thought it is when viewed from non-default lang maybe with AOS installed, But didn't figure it out yet. It was broken in such a way, that I could choose not just English, but English (American) and English (British) from the dropdown for a PW language (and there were no default lang tab, but that is another story).

Any way, I happened to make wrong settings. When I did try to translate a field the popover with translate label never went away. I checked the browser dev tool s console and say an error from an xhr request that was not handled. I think Fluency should show an error message instead.

SkyLundy commented 3 years ago

Better error handling is something that needs to be built in. If you run into that again can you copy/paste the error here so I can better see what it is? Better error handling is planned.

The languages that are listed are taken directly from DeepL. There aren't any languages hard coded in the module so whatever languages DeepL offers are what is available to select. The module doesn't make any changes to the languages or set any preferences.

Please screenshot errors when possible and paste them here when they are in the console. I'll leave this issue open in case you can get the errors and post them here.

ivangretsky commented 3 years ago

I do not remember the exact error, but it happened when DeepL API responded with a non-200 code, It was caused by sending a language code in a request that DeepL does not recognize. When Fluency received such a response it did not remove the field overlay, nor did it alert the user in any other way.

SkyLundy commented 3 years ago

I will keep an eye out for this error. All of the languages that are used in the UI are pulled from the DeepL API so there shouldn't be a request that DeepL doesn't recognize because only the languages it understands are available to begin with.

There may be an issue if the DeepL service is temporarily down or unavailable, or if the server has a problem making the request. I'll be adding better error handling.