amaGama returns a 404 with same language pairs

[jason-p-pickering]

Use case-Improvement of template language messages. In this case, the user is translating the template languages (in English) to English.

When translating in the /en/ project, a request is issued to Amagama.

An error message results in Pootle due to the 404

Perhaps an HTTP 204 would be more appropriate?

[unho]

amaGama itself avoids handling translation from same language to same language: https://github.com/translate/amagama/blob/master/amagama/tmdb.py#L441-L443 Perhaps this is not dealt with in the best way on the amaGama side, but the point is that Pootle should avoid sending requests for getting translation suggestion from a language to the same language.

[leonardcj]

You might ask why this matters, but the use-case is actually important. I routinely "translate" new projects into the lang-en project as a review for i18n issues. Pootle conveniently allows me to flag strings as "Needs Work", with the understanding that the work needed is on i18n, not L10n.

[unho]

My understanding is that in that particular use-case results from amaGama are unnecessary.

[dwaynebailey]

There are three aspects here:

1. Response code for non-results. I think @jason-p-pickering is right here that 404 is probably wrong, but I'm not sure if 204 is better.
2. Pootle shouldn't be asking amaGama for results when the pairs are the same. Though I'd want to at least check the en_US:en_GB are not see as en:en pairs, same for pt and fr that might be asking for regional dialects.
3. Pootle should handle 404 better as there might be other times when amaGama returns a 404.

[jason-p-pickering]

@dwaynebailey , I think maybe a 400 Bad Request is better in this case?

[dwaynebailey]

Just for reference https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

400 might be better, but I haven't looked carefully at the available options.

[unho]

Landed the fix in fa7c118 to prevent querying amaGama if source and target language are the same. amaGama issues still to be addressed on amaGama side.

[dwaynebailey]

Reopening this. Pootle will still fail if it gets a 404 as far as I can understand, so this is a workaround but its not fixing the core issue that Pootle won't fail correctly if amaGama is broken in some way.

[unho]

No, it won't fail. It will catch the error and will just display the message seen in the screenshot in the first message in the issue. See https://github.com/translate/pootle/blob/master/pootle/static/js/editor/app.js#L1056-L1079 for the shared handling code.

[jason-p-pickering]

From a translation perspective, I think if Amagama fails for whatever
reason, Pootle should simply swallow the error (possibly logging the
occurrence in the JavaScript console) but not continually display the error
message to the translator. The memory there is to help the translator, but
if the service does not work, then I don't think we should penalize the
translator to see the error message each and every time it occurs.

I am not sure if this is what happens but from a usability standpoint, this
would seem to make sense.

[unho]

Created translate/amagama#3210 to track the amaGama side of things.

[unho]

Created #4771 to track the bigger issue with XHR request failures on Pootle.

As a result I will be closing this issue.