Seeing these in production: Task was called with args: ('fjord.feedback.models:Response:4506067', 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/input.mozilla.org/input/vendor/src/celery/celery/task/trace.py", line 233, in trace_task R = retval = fun(*args, **kwargs) File "/data/www/input.mozilla.org/input/vendor/src/celery/celery/task/trace.py", line 420, in __protected_call__ return self.run(*args, **kwargs) File "/data/www/input.mozilla.org/input/fjord/translations/tasks.py", line 35, in translate_task translate(instance, system, src_lang, src_field, dst_lang, dst_field) File "/data/www/input.mozilla.org/input/fjord/translations/utils.py", line 32, in translate trans_system.translate(instance, src_lang, src_field, dst_lang, dst_field) File "/data/www/input.mozilla.org/input/fjord/translations/models.py", line 226, in translate instance.id, lc_src, dst_lang, text) File "/data/www/input.mozilla.org/input/fjord/translations/gengo_utils.py", line 75, in _requires_keys return fun(self, *args, **kwargs) File "/data/www/input.mozilla.org/input/fjord/translations/gengo_utils.py", line 239, in machine_translate resp = self.gengo_api.postTranslationJobs(jobs=data) File "/data/www/input.mozilla.org/input/vendor/src/gengo-python/gengo/gengo.py", line 295, in get results['err']['code']) 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.

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 gengo_utils.py 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.

Landed in master: https://github.com/mozilla/fjord/commit/e59d4f6 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.