Handling unsupported language pairs

I just noticed that all installed languages are displayed, however if “pivot” models are not installed it can cause this error

Example of installed models:

  • en → es
  • es → en
  • en → nl

The nl → es translation will therefore not work because no model is installed for

- @dingedi

I noticed en->ca is currently broken with a similar issue on libretranslate.com. This is occuring because ca->en is installed so English and Catalan are displayed in the user interface as available then fail when you try to translate English to Catalan.

We should figure out a good way to deal with this type of issue. In future versions of Argos Translate I’m planning to move to multilingual models so this should happen less frequently.

I think the best solution is probably to have a better error response at the API level and more descriptive feedback in the graphical user interface.

We could have a language_pairs endpoint that returns something like this:

[[en, ca],[ca,en],[en,es]]

One issue with this approach is that this list could become very long if we want to support 200+ languages in the future. The list would be O(n^2) for the number of languages n so 200^2=40000. I don’t think this is a huge deal though, if the response is less than 1MB lots of other web applications are downloading larger JavaScript tracking scripts :joy:. However searching this list might be slow.

Another solution would be to add an API endpoint to check if a specific language pair is supported. This could be a standalone endpoint or we could add functionality to mark an API request as a test and get a response telling you if it’s a valid request.

I’ve found that extending /languages to include an additional targets field should work without breaking backward compatibility and without needing an additional endpoint. I’ll modify the JS client as well and do some checks server side. #358


- @pierotofy

I like this solution.

I also figured out that the English->Catalan issue was a bug in the package index.