No error is raised when an translation fails to be associated with a component via the REST API

[superDross]

Describe the bug

When associating a language/translation to a component via the REST API , we sometimes get this response back:

{'data': {'language_code': '', 'filename': '', 'revision': ''}} 

When trying to get the associated translation via the REST API, we get a 404 response.

This seems to occur when the components template files are present in the git repo in the cloud, but not in the local repo that Weblate uses for managing translations.

This is resolved when the appropriate templates (both the template and monolingual base file) are pulled down into the local Weblate repo.

To Reproduce

Steps to reproduce the behavior:

1. create some template files (pot and monolingual base file) in your local data repo and git push the changes
2. do not pull these changes into your local weblate instance
3. create a monolingual GETTEXT component and ensure the Templates for new translation and Monolingual base language file fields refer to the aforementioned template files
4. make a POST request to associate a translation with your newly created component
5. make a GET request for the newly associated translation, you should receive a 404 response

To Resolve:

6. In the Weblate UI go to project -> component -> manage -> repository status -> Pull, to pull the template files down
7. repeat steps 4 & 5, you should get a 201 response

Expected behavior

When associating a language/translation to a component via the REST API , we should get an appropriate error message stating the reason why the translation can not be associated with the component instead of a 201 response with {'data': {'language_code': '', 'filename': '', 'revision': ''}} .

Server configuration and status

 * Weblate: 4.1.1
 * Django: 3.0.8
 * siphashc: 1.3
 * Whoosh: 2.7.4
 * translate-toolkit: 3.0.0
 * lxml: 4.5.2
 * Pillow: 7.1.2
 * bleach: 3.1.5
 * python-dateutil: 2.8.1
 * social-auth-core: 3.3.3
 * social-auth-app-django: 3.4.0
 * django-crispy-forms: 1.9.2
 * oauthlib: 3.1.0
 * django-compressor: 2.4
 * djangorestframework: 3.11.0
 * django-filter: 2.3.0
 * django-appconf: 1.0.4
 * user-agents: 2.1
 * filelock: 3.0.12
 * setuptools: 40.8.0
 * jellyfish: 0.8.2
 * openpyxl: 3.0.1
 * celery: 4.4.7
 * kombu: 4.6.11
 * translation-finder: 2.1
 * html2text: 2020.1.16
 * pycairo: 1.16.2
 * pygobject: 3.30.4
 * diff-match-patch: 20181111
 * requests: 2.24.0
 * django-redis: 4.12.1
 * hiredis: 1.1.0
 * sentry_sdk: 0.15.1
 * Cython: 0.29.21
 * misaka: 2.1.1
 * GitPython: 3.1.7
 * borgbackup: 1.1.13
 * pyparsing: 2.4.7
 * Python: 3.7.3
 * Git: 2.20.1
 * psycopg2: 2.8.5
 * psycopg2-binary: 2.8.5
 * phply: 1.2.5
 * chardet: 3.0.4
 * ruamel.yaml: 0.16.10
 * tesserocr: 2.5.1
 * akismet: 1.1
 * boto3: 1.14.33
 * zeep: 3.4.0
 * aeidon: 1.7.0
 * iniparse: 0.5
 * mysqlclient: 2.0.1
 * Mercurial: 5.4.2
 * git-svn: 2.20.1
 * git-review: 1.28.0
 * hub: 2.13.0
 * lab: 0.16
 * Redis server: 5.0.9
 * PostgreSQL server: 11.8
 * Database backends: django.db.backends.postgresql
 * Cache backends: default:RedisCache, avatar:FileBasedCache
 * Email setup: django.core.mail.backends.smtp.EmailBackend: smtp.mailtrap.io
 * OS encoding: filesystem=utf-8, default=utf-8
 * Celery: redis://cache:6379/1, redis://cache:6379/1, regular
 * Platform: Linux 5.4.62-1-MANJARO (x86_64)

[github-actions]

Thank you for your report, the issue you have reported has just been fixed.

• In case you see a problem with the fix, please comment on this issue.
• In case you see a similar problem, please open a separate issue.
• If you are happy with the outcome, consider supporting Weblate by donating.