RE: Reply for LPS-183137 / LPS-187034 breaks DeepL

2023-07-10T09:34:25Z

Thanks a lot for the fix. We've created the ticket and sent a PR linked to it: https://github.com/liferay-lima/liferay-portal/pull/4458.

RE: Reply for LPS-183137 / LPS-187034 breaks DeepL

2023-07-10T15:14:38Z

PR opened: https://github.com/liferay-lima/liferay-portal/pull/4453 (at this point without an issue ID)

Reply for LPS-183137 / LPS-187034 breaks DeepL

2023-07-07T01:26:21Z

I was pinged by @Austin on JIRA in LPS-183137. As I can't work there anymore, I need a secretary here to push the information into the JIRA instrance:

Please add a reply in https://liferay.atlassian.net/browse/LPS-183137 (feel free to replace the last two sentences with a reference to the new issue):

@Austin: Yes I can reproduce the problem. I also analysed it and found the issue in the refactoring done in LPS-187034. There are two different URLs used by the DeepL translator. One is used to fetch the valid languages and the second to do the translation. The mentioned issue ignores that and always uses the "validatedLanguageUrl". I have a tested fix ready. As I can't open issues anymore I have to wait till one is opened for me.

Please create a new issue to track the problem introduces by LPS-187034, so that I can reference it with a PR:

Component:

DeepL Translator

Title:

Wrong URL used for requesting translation in DeepL

Text:

The refactoring of the DeepL translator code to use the company configuration as basis for requests (LPS-187034) breaks translations because the wrong URL is used to create translation requests. There are two different URLs used by the DeepL translator. One is used to fetch the valid languages (validatedLanguageUrl) and the second to do the translation (url). After the refactoring for both cases `validatedLanguageUrl` is used, which breaks the translation call.

I have a fix ready, I just need the issue ID.