Closed Bug 1033852 Opened 9 years ago Closed 9 years ago

[traceback] GengoError: machine translation language service not supported


(Input :: General, defect, P1)



(Not tracked)



(Reporter: willkg, Assigned: willkg)


(Whiteboard: u=dev c=translations p=1 s=input.2014q3)

Seeing these in production:

Task was called with args: ('', u'gengo_machine', 'zh-CN', 'description', u'en', 'translated_description') kwargs: {}.

The contents of the full traceback was:

Traceback (most recent call last):
  File "/data/www/", line 233, in trace_task
    R = retval = fun(*args, **kwargs)
  File "/data/www/", line 420, in __protected_call__
    return*args, **kwargs)
  File "/data/www/", line 35, in translate_task
    translate(instance, system, src_lang, src_field, dst_lang, dst_field)
  File "/data/www/", line 32, in translate
    trans_system.translate(instance, src_lang, src_field, dst_lang, dst_field)
  File "/data/www/", line 226, in translate, lc_src, dst_lang, text)
  File "/data/www/", line 75, in _requires_keys
    return fun(self, *args, **kwargs)
  File "/data/www/", line 239, in machine_translate
    resp = self.gengo_api.postTranslationJobs(jobs=data)
  File "/data/www/", line 295, in get
GengoError: u'machine translation language service not supported'

That's coming from celery when it tries to do a translation job for a machine translation.

This bug covers handling that exception and journaling the details so it's not sending me error mail.
Making this a P1 and adding whiteboard data. We should fix this asap so we can start aggregating the errors in the journal instead of having me get error email.
Priority: -- → P1
Whiteboard: u=dev c=translations p= s=input.2014q3
A few thoughts on this:

It's annoying it's a GengoError like all the other errors. We'll probably need to differentiate it on the error code.

The language service pairs API doesn't talk about their machine translation at all. I'm guessing this is because they don't actually do the machine translation--they pass it off to Bing or something like that. Given that, I don't think there's a good programmatic way for us to divine what they do and don't support.

With the language service pairs, we fetch the list from Gengo and then keep it as a module-level variable. When we do the next deploy, the processes restart, so that causes us to get a fresh list. In this way, we're pretty up-to-date with changes to the language service pairs.

Given all that, these are some implementation options:

1. We maintain a list of languages that aren't supported in the db and update it as we discover new ones. We cache this list so we're not doing tons of db hits.

2. We maintain a list of languages that aren't supported in settings or in the file and update it periodically. It probably doesn't change much, so this is probably good enough for now though it does codify the list in a way that makes it hard to know if there are changes.

I think we should go with 2 for now and then make it better later if there's a compelling need to.
Given the last comment, I'm estimating this at 1 point.
Whiteboard: u=dev c=translations p= s=input.2014q3 → u=dev c=translations p=1 s=input.2014q3
Landed in master:

Pushed to prod just now. Marking this as FIXED. This isn't a great solution, but it's good enough for now. If we need a better one, we can open up a new bug and reference this one.
Closed: 9 years ago
Resolution: --- → FIXED
Assignee: nobody → willkg
You need to log in before you can comment on or make changes to this bug.