URL links for source file names containing special characters need encoding

[SlavekB]

Describe the issue

File names referenced as source location of translation are listed as local file names. Such files may contain, for example, the + character. When using such names for URL links, it is necessary to use encoding, so otherwise it is created as incorrect link == is evaluated as non-existent.

Here is not a solution to change the source file names, not even convince gettext to generate URL encoded source locations.

I already tried

Describe the steps you tried to solve the problem yourself.

• I performed verification in all versions since 2019 (Weblate 3.x) – it always worked wrong.

To Reproduce the issue

Steps to reproduce the behavior:

1. Go to example on TDE Weblate/application/tdeio-apt - desktop files or TDE Weblate/tdesdk/tdefile - desktop files
2. Scroll down to 'Source string location'
3. Look that the link for apt.protocol is fine while the link to apt+http.protocol and c++/tdefile_cpp.desktop is incorrect.
4. See error when you click on the link for apt+http.protocol.

Expected behavior

I expect that links to source locations will be encoded for use in the URL.

Server configuration and status

Weblate installation: PyPI

 * Weblate: 4.8
 * Django: 3.2.4
 * siphashc: 1.3
 * translate-toolkit: 3.4.0
 * lxml: 4.6.3
 * Pillow: 7.1.2
 * bleach: 3.1.5
 * python-dateutil: 2.8.1
 * social-auth-core: 4.1.0
 * social-auth-app-django: 5.0.0
 * django-crispy-forms: 1.9.0
 * oauthlib: 3.1.0
 * django-compressor: 2.4
 * djangorestframework: 3.11.0
 * django-filter: 2.4.0
 * django-appconf: 1.0.4
 * user-agents: 2.1
 * filelock: 3.0.12
 * setuptools: 46.1.3
 * jellyfish: 0.7.2
 * openpyxl: 3.0.3
 * celery: 5.1.1
 * kombu: 5.1.0
 * translation-finder: 2.7
 * weblate-language-data: 2021.5
 * html2text: 2020.1.16
 * pycairo: 1.19.1
 * pygobject: 3.36.1
 * diff-match-patch: 20200713
 * requests: 2.23.0
 * django-redis: 4.11.0                                                                  [2/34]
 * hiredis: 1.0.1
 * sentry_sdk: 0.14.3
 * Cython: 0.29.17
 * misaka: 2.1.1
 * GitPython: 3.1.2
 * borgbackup: 1.1.11
 * pyparsing: 2.4.7
 * pyahocorasick: 1.4.1
 * python-redis-lock: 3.7.0
 * Python: 3.7.3
 * Git: 2.20.1
 * psycopg2-binary: 2.8.5
 * phply: 1.2.5
 * chardet: 3.0.4
 * ruamel.yaml: 0.16.10
 * boto3: 1.14.7
 * aeidon: 1.7.0
 * iniparse: 0.5
 * Mercurial: 4.8.2
 * git-svn: 2.20.1
 * git-review: 1.27.0
 * Redis server: 5.0.3
 * PostgreSQL server: 11.12
 * Database backends: django.db.backends.postgresql
 * Cache backends: default:RedisCache, avatar:FileBasedCache
 * Email setup: django_sendmail_backend.backends.EmailBackend: localhost
 * OS encoding: filesystem=utf-8, default=utf-8
 * Celery: redis://localhost:6379, redis://localhost:6379, regular
 * Platform: Linux 3.16.6-042stab141.42 (x86_64)

Weblate deploy checks

System check identified no issues (3 silenced).

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

[SlavekB]

Please how can I verify that the problem is not caused during the retrieval of the source locations from PO / POT files? I tried to backport the appropriate patch, but the situation remained unchanged. See examples mentioned above.

[SlavekB]

I tried to search in the Weblate database dump and the source location links appear to be incorrectly extracted and stored in the database: apt http.protocol:9, apt.protocol:9 => + character is missing in the database. The fix will probably require the second part of the puzzle.

[nijel]

Yes, translate-toolkit seems to do urldecoding when parsing the PO file. It was introduced in translate/translate@36a9134. I've already had some issues with that, see translate/translate#3466. But anyway this part has to be addressed in the translate-toolkit.