Gettext comments are not analyzed when source file is uploaded again

[luebbe]

How I discovered the problem:

I've uploaded a bunch of .po files and one .pot template via API as a .zip file to our weblate instance. Later I noticed that our .pot extractor has missed some c-format msgids. So I fixed the .pot extractor and uploaded the .pot file again.

API used:

POST /api/translations/(string: project)/(string: component)/en/file/
'method ', 'source'

I chose 'method ': 'source', because I wanted Weblate to update the existing translations. So the .pot files are identical apart from a handful of extra c-format comments in the second upload.

Example
Upload 1:

#: TreeFilter.dfm
msgid "%d items in filter"
msgstr ""

Upload 2:

#: TreeFilter.dfm
#, c-format
msgid "%d items selected"
msgstr ""

The msgid "%d items selected" did not receive the c-format tag after the second upload.

My theory: The comments are not analyzed again, when the .pot file is re-uploaded.

I already tried

When I delete the component and re-create it from the .pot file with the c-format comments, the msgids receive the c-format tag as expected. So the parsing itsel works correctly on the initial upload.

To Reproduce the issue

Steps to reproduce the behavior:

Everything was done via the API, but can probably be done the same way via the UI

1. create a component from a .po(t) file which doesn't contain c-format comments
2. check that the translation string doesn't have the c-format tag
3. upload a new translation source file which now contains a c-format comment for the same string
4. the translation string didn't receive the c-format tag

Expected behavior

That the c-format tag can be turned on/off on translation strings by uploading a .po(t) file with/without c-format comments.

Server configuration and status

Weblate installation: Weblate 4.5.1 on Docker

[nijel]

The flags change should be detected. Was the translation file (PO) updated? Does it contain the flag?

[luebbe]

no, not the .po files. I just updated the .pot file and expected that changes there would propagate to all languages. I can check again on monday, but IIRC the source language (en) didn't contain the flag after the .pot was updated.

[nijel]

The po files should be updated on such upload. I'm trying to figure out which part is broken

[luebbe]

Hi Nijel,
I tried to come up with a MRE this morning and either this is a case of self-healing software (over the weekend) again, which I hardly believe or there is something that I've been missing last week.

Short version: it works as expected with the attached MRE.
Long version: I went through the steps four times (twice via UI, twice via API)

In the hope that it will be useful to create a test case, I attach my example

Example.zip contains three strings where c-format is turned on/off.

1. Create a component using c_format.zip from the example (doesn't contain c-format tag)
   Check German translaton on the UI (no c-format tag)
2. Upload c_format_on.pot
   Check German translaton on the UI (c-format tag is there)
3. Upload c_format_off.pot
   Check German translaton on the UI (c-format tag is gone)

This is a very small example. The only thing that I can imagine right now is that under the hood weblate wasn't finished yet with parsing the uploaded .pot file (200k real data), although it said so on the "insights" page. But it should have been a few minutes after the upload, because I checked for the c-format tag several times.
Is there any place where I can monitor (via API) when a task is finished? There is a task_url mentioned in the API docs, but I honestly have no idea how to use it.

[github-actions]

This issue has been automatically marked as stale because there wasn’t any recent activity.

It will be closed soon if no further action occurs.

Thank you for your contributions!

[nijel]

The API for tasks is documented here: https://docs.weblate.org/en/latest/api.html#tasks

[luebbe]

The problem is that there is absolutely no hint where the uuid comes from. This is the only place where the term 'uuid' appears in the docs, so it's a well kept secret.

[nijel]

You get the full API URL in task_url, it includes task UUID as well.

[luebbe]

So if I understand that correctly, after any action that I wish to (or need to) monitor I have to requeste <weblate_url>/api/components/<project>/<component>, get the task_url from that response and monitor the given url?
Not very straightforward, but if it is like that I'll follow this road.
Wouldn't it make sense to include the task_url already in the responst to the first request, which triggers the action? Or is it not know yet at that time? It would save one round trip.

[nijel]

IMHO it should be already present.

[luebbe]

Meanwhile the subject of this issue has drifted a bit :)
You're right, the task_url is returned when a component is created. It is mentioned nowhere else in the docs, so this is surely the only place where it is returned.
My idea was to return the task_url whenever a potentially time consuming action is triggered. If you say that uploading a new translation source file with > 2000 msgids is 'not noticeable' then I'm fine with it. If it takes a minute or two to parse the upload, merge with all languages, run all checks, etc, then returning a task_url might make sense.