Creating a new unit with REST API results in random, hexadecimal key

[jeanreis]

Describe the issue

When I create a new translation unit using the REST API, the unit is created with the correct value, but the key is a (seemingly) random hexadecimal value. For example, attempting to create a unit with key "TestKey" results in a unit with key "0x81f0a4746646681" instead (the value is correct).

I already tried

Tried both JSON and x-www-form-urlencoded payloads, tried different types of keys (only letters, alphanumeric, only numbers, etc.).
Tried calling the API with both Postman and cURL (on the CLI).
Creating keys through the Web UI works as expected, it's just the REST API that shows this behaviour.

To Reproduce the issue

Steps to reproduce the behavior:

1. Use Weblate from Docker, locally (i.e. localhost:8080)
2. Create a new project (test-001) and component (db), set up VCS with a git repo;
3. Add a base file, monolingual - I used i18next JSON format to the repo, push and let Weblate sync;
4. Perform the following API call:

   curl --location --request POST 'http://127.0.0.1:8080/api/translations/test-001/db/en/units/' \
   --header 'Authorization: Token <TOKEN>' \
   --header 'Content-Type: application/json' \
   --data-raw '{
       "key": "TestKey",
       "value": ["This is the content for TestKey"]
   }'
   

Expected behavior

A new translation unit with key "TestKey" is created.

Server configuration and status

Docker running locally.

 * Weblate: 4.4.2
 * Django: 3.1.5
 * siphashc: 2.1
 * Whoosh: 2.7.4
 * translate-toolkit: 3.3.0
 * lxml: 4.6.2
 * Pillow: 8.1.0
 * bleach: 3.2.1
 * python-dateutil: 2.8.1
 * social-auth-core: 4.0.3
 * social-auth-app-django: 4.0.0
 * django-crispy-forms: 1.10.0
 * oauthlib: 3.1.0
 * django-compressor: 2.4
 * djangorestframework: 3.12.2
 * django-filter: 2.4.0
 * django-appconf: 1.0.4
 * user-agents: 2.2.0
 * filelock: 3.0.12
 * setuptools: 40.8.0
 * jellyfish: 0.8.2
 * openpyxl: 3.0.5
 * celery: 5.0.5
 * kombu: 5.0.2
 * translation-finder: 2.7
 * weblate-language-data: 2020.13
 * html2text: 2020.1.16
 * pycairo: 1.16.2
 * pygobject: 3.30.4
 * diff-match-patch: 20200713
 * requests: 2.25.1
 * django-redis: 4.12.1
 * hiredis: 1.1.0
 * sentry_sdk: 0.19.5
 * Cython: 0.29.21
 * misaka: 2.1.1
 * GitPython: 3.1.12
 * borgbackup: 1.1.15
 * pyparsing: 2.4.7
 * Python: 3.7.3
 * Git: 2.20.1
 * psycopg2: 2.8.6
 * psycopg2-binary: 2.8.6
 * phply: 1.2.5
 * chardet: 4.0.0
 * ruamel.yaml: 0.16.12
 * tesserocr: 2.5.1
 * akismet: 1.1
 * boto3: 1.16.54
 * zeep: 4.0.0
 * aeidon: 1.9
 * iniparse: 0.5
 * mysqlclient: 2.0.3
 * Mercurial: 5.6.1
 * git-svn: 2.20.1
 * git-review: 1.28.0
 * Redis server: 6.0.10
 * PostgreSQL server: 13.1
 * Database backends: django.db.backends.postgresql
 * Cache backends: default:RedisCache, avatar:FileBasedCache
 * Email setup: django.core.mail.backends.smtp.EmailBackend: smtp.example.com
 * OS encoding: filesystem=utf-8, default=utf-8
 * Celery: redis://cache:6379/1, redis://cache:6379/1, regular
 * Platform: Linux 4.19.121-linuxkit (x86_64)

Weblate deploy checks

SystemCheckError: System check identified some issues:

CRITICALS:
?: (weblate.E003) Cannot send e-mail ([Errno -2] Name or service not known), please check EMAIL_* settings.
	HINT: https://docs.weblate.org/en/weblate-4.4.2/admin/install.html#out-mail

WARNINGS:
?: (security.W004) You have not set a value for the SECURE_HSTS_SECONDS setting. If your entire site is served only over SSL, you may want to consider setting a value and enabling HTTP Strict Transport Security. Be sure to read the documentation first; enabling HSTS carelessly can cause serious, irreversible problems.
?: (security.W008) Your SECURE_SSL_REDIRECT setting is not set to True. Unless your site should be available over both SSL and non-SSL connections, you may want to either set this setting True or configure a load balancer or reverse-proxy server to redirect all connections to HTTPS.
?: (security.W012) SESSION_COOKIE_SECURE is not set to True. Using a secure-only session cookie makes it more difficult for network traffic sniffers to hijack user sessions.
?: (security.W018) You should not have DEBUG set to True in deployment.

INFOS:
?: (weblate.I021) Error collection is not set up, it is highly recommended for production use
	HINT: https://docs.weblate.org/en/weblate-4.4.2/admin/install.html#collecting-errors
?: (weblate.I028) Backups are not configured, it is highly recommended for production use
	HINT: https://docs.weblate.org/en/weblate-4.4.2/admin/backup.html

System check identified 7 issues (1 silenced).

[nijel]

I've just tried:

curl --data key=key2 --data value=value2  -H "Authorization: Token TOKEN" http://127.0.0.1:8000/api/translations/test/i18next/en/units/

It results in:

diff --git i18next/en.json i18next/en.json
index fb3a7be..fa99181 100644
--- i18next/en.json
+++ i18next/en.json
@@ -3,5 +3,6 @@
     "apple": "I have an apple",
     "apple_plural": "I have {{count}} apples",
     "apple_negative": "I have no apples",
-    "key": "value"
+    "key": "value",
+    "key2": "value2"
 }

What looks correct to me.

I'm testing on 4.5-dev though and there were quite some changes in the related code, so I assume that it was fixed. Most likely as a side effect of other changes, most likely f2dc694.

[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, don’t hesitate to support Weblate by making a donation.