some source strings can't be translated - no input fields

[ReneBoehm]

Describe the issue

We are using a dockerized weblate 4.10.1 with gettext (po), monolingual po files and source strings (templates) in a pot file (no translation contained in this file). We're experiencing some strange behaviour which we can't explain. Some source strings can't be translated. There are no input fields to do so. Only the source language. Switching to the previous or next source string shows the input fields for the other languages (English and German).
Some of the affected source strings are contained in multiple components, others exist only in one component. Something noticeable is that the affected strings show zero "other languages" while other untranslated strings show the two target languages in "other languages" even if there is no translation. This is what I would expect btw.

I'm pretty sure there's some logic behind that but even reading through the documentation didn't bring up any explanation so far.

Btw. we are using weblate in this project for more than 3 years now and never experienced that behaviour. The last update of weblate was today from version 4.4 to 4.10.1.

I already tried

• I've read and searched the documentation.
• I've searched for similar issues in this repository.

Steps to reproduce the behavior

that's the big question...

Expected behavior

No response

Screenshots

No response

Exception traceback

No response

How do you run Weblate?

Docker container

Weblate versions

• Weblate: 4.10.1
• Django: 4.0
• siphashc: 2.1
• translate-toolkit: 3.5.1
• lxml: 4.7.1
• Pillow: 8.4.0
• bleach: 4.1.0
• python-dateutil: 2.8.2
• social-auth-core: 4.1.0
• social-auth-app-django: 5.0.0
• django-crispy-forms: 1.13.0
• oauthlib: 3.1.1
• django-compressor: 3.1
• djangorestframework: 3.13.1
• django-filter: 21.1
• django-appconf: 1.0.5
• user-agents: 2.2.0
• filelock: 3.4.0
• setuptools: 60.0.4
• jellyfish: 0.8.9
• openpyxl: 3.0.9
• celery: 5.2.1
• kombu: 5.2.2
• translation-finder: 2.10
• weblate-language-data: 2021.7
• html2text: 2020.1.16
• pycairo: 1.20.1
• pygobject: 3.42.0
• diff-match-patch: 20200713
• requests: 2.26.0
• django-redis: 5.2.0
• hiredis: 2.0.0
• sentry_sdk: 1.5.1
• Cython: 0.29.26
• misaka: 2.1.1
• GitPython: 3.1.24
• borgbackup: 1.1.17
• pyparsing: 3.0.6
• pyahocorasick: 1.4.2
• python-redis-lock: 3.7.0
• Python: 3.10.1
• Git: 2.30.2
• psycopg2: 2.9.2
• psycopg2-binary: 2.9.2
• phply: 1.2.5
• chardet: 4.0.0
• ruamel.yaml: 0.17.17
• tesserocr: 2.5.2
• akismet: 1.1
• boto3: 1.20.26
• zeep: 4.1.0
• aeidon: 1.10.1
• iniparse: 0.5
• mysqlclient: 2.1.0
• Mercurial: 6.0
• git-svn: 2.30.2
• git-review: 2.2.0
• Redis server: 6.2.6
• PostgreSQL server: 12.9
• Database backends: django.db.backends.postgresql
• Cache backends: default:RedisCache, avatar:FileBasedCache
• Email setup: django.core.mail.backends.smtp.EmailBackend: mail.cape-it.de
• OS encoding: filesystem=utf-8, default=utf-8
• Celery: redis://cache:6379/1, redis://cache:6379/1, regular
• Platform: Linux 3.16.0-4-amd64 (x86_64)

Weblate deploy checks

SystemCheckError: System check identified some issues:

CRITICALS:
?: (weblate.E018) Failed to download avatar: HTTPSConnectionPool(host='www.gravatar.com', port=443): Max retries exceeded with url: /avatar/77a4accfa1d1d8fcae8e2f3fd42eb1de?d=identicon&s=32 (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x7fe88ff9bb50>, 'Connection to www.gravatar.com timed out. (connect timeout=1.0)'))
	HINT: https://docs.weblate.org/en/weblate-4.10.1/admin/optionals.html#avatars

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.

INFOS:
?: (weblate.I021) Error collection is not set up, it is highly recommended for production use
	HINT: https://docs.weblate.org/en/weblate-4.10.1/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.10.1/admin/backup.html

System check identified 6 issues (1 silenced).

Additional context

No response

[github-actions]

This issue looks more like a support question than an issue. We strive to answer these reasonably fast, but purchasing the support subscription is not only more responsible and faster for your business but also makes Weblate stronger.

In case your question is already answered, making a donation is the right way to say thank you!

[nijel]

When source string is marked as needing editing, editing of translations is disabled. Maybe that's the reason? Anyway the reason should be visible on the translate page...

[ReneBoehm]

Where should I look ?

This is one of the strings that are not translatable:

This is the one before, which is translatable:

[nijel]

Both are read-only according to flags, so neither of them should be editable (this is expected in the bilingual formats, the source language is not editable because it is typically extracted from the source code).

[ReneBoehm]

That's right. We don't edit the source strings as they are extracted from the code. I guess we're doing something wrong but I can't figure it out. The non-translatable source strings don't even show up in the list of strings in the target languages, when browsing. And they are not listed in the "not translated strings" list.

[ReneBoehm]

IMHO that's the issue. This also explains why there are zero "other languages" available when looking at the source string. But why ?

[ReneBoehm]

Thank god, I've found the reason. There where duplicates in the .po files. Maybe someone edited them directly. So msgmerge had a problem with that. I've remove the duplicates and now the source strings show up in the lists.

[ReneBoehm]

FYI: the reason was that a developer fixed a typo in the pot file and fixed it in the de.po too. Unfortunately the source string (msgid) without the typo was already contained in the translation too...

[github-actions]

The issue you have reported is now resolved. If you don’t feel it’s right, please follow its labels to get a clue for further steps.

• 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.