Initializing a component from a .zip file does not respect the template file #95
Comments
|
|
Thank you for your report; the issue you have reported has just been fixed.
|
Fine 👍 Thank you.
That's why I put a green check-mark next to 3. The real problem is:
Or did Github screw up the numbering when you quoted the reproduction steps and you are referring to my Step 4? Is this really good behaviour? It doesn't make sense to me. We're starting with a blank sheet of paper here. Why whould I upload a .pot file in the .zip when its contents are ignored by Weblate? My expectation is that, when a .pot file (or any template FWIW) is provided together with the .po files, msgmerge should be run against this .pot file. So this means that I should activate the: https://docs.weblate.org/en/latest/admin/addons.html#addon-weblate-gettext-msgmerge plugin for all gettext based components? But IIRC this can only be done after the component has been created. Aren't we running into a chicken/egg problem here? I create a project from a .zip that contains .pot and .po files. The add-on description says that it will be triggered, when upstream changes are detected. But the data is already in Weblate. There are no upstream changes, the .pot contains the strings to translate but some .po files don't match the .pot (yet). So the add-on is not going to be triggered and the translators think that everything is fine, while in fact it isn't. |
|
Yes, GitHub changed rendering to ordered list and messed up numbers. Weblate has no clue whether the difference between the PO files are intentional or not. We try not to break things, and enabling msgmerge by default could break things if it is not intended. The addon is triggered on installation as well, so everything should be fine. |
|
OK, I understand your reasoning. My goal is to make setting up a weblate translation project from a developer's working copy and interacting with it as painless as possible. The Weblate UI should just be used for translation. No configuration should be done via the UI. Everything should done via a (homebrew) API client. Right now I don't see how I coud find the id of the msgfmt addon via the API. I'm trying to understand what is going on, when a component is initialized from a .zip file: Stage 1
Is this correct? Result:
Stage 2
Result:
The result after Stage 2 is the desired state after Stage 1 for me. I'm working with translations for more than 25 years now, using different web based, desktop, proprietary and open source translation tools and it is the first time that I come across this behaviour. "Add an option to the component initialization to run msgmerge immediately". Basically combine Step 1 and Step 2, so the option could be named "update source", like in file upload or API What do you think about this? |
|
I understand your point - it makes perfect sense if you use xgettext to automatically update PO files. On the other side, the PO files are often used just a storage for the translations as that is widely used format and there is no xgettext involved. The POT file is used only for starting new translations and further management of the strings happens by other means. In case you are expencting this behavior for all PO files, you can add the addon to DEFAULT_ADDONS - it will make it automatically install on all newly created components. |
|
Yes, you're right. The translations in the Open Source projects that I'm involved in (e.g. TortoiseSVN, PyScripter) as well as the translations at work are all centered around xgettext or other extraction tools that create .pot files from different sources. This is why this behaviour is so cruicial to me. The pot files are the reference :) I'll try the default_addons. Thank you for the hint. |
|
Sorry, but it still doesn't work. The addon is added to the default add ons with the options But after that was solved it looks like we're good to go: When I go to weblate/api/addons, the list is empty ✔️ Notice that true,false,true are reflected as in the DEFAULT_ADDONS configuration.
Now I go to the addon configuration of the "pot_not_honored" component and see the following:
Where are the true,false,true settings gone? So AFAICT
|
|
This looks wrong, there should not be two "configuration" blocks, the keys should be part of the first one:
Any errors in the logs? Any alerts on the newly created component indicating a problem? |
Yes, that's what I noticed yesterday and wrote above. I asked our admin to fix it, which he just did: Went through steps 1-4 again with the same wrong result. The add-on configuration looks good to me now:
I don't have access to the server (docker), so I have to tell my admin exactly in which log he has to look for what. The only alert on the component is that the license information is missing. This is what is visible to me from the insights:
Translation status is shown as 100% |
|
See https://docs.weblate.org/en/latest/contributing/debugging.html#weblate-logs for info on logging. |
|
Here's some filtered output of the log during component creation from zip Created with: I don't see anything evil here. I see that the addon is enabled immediately. I also see that it couldn't be enabled for the glossary. I also see no trace that the addon ever executed. Before and after are just GET requests on the component |
To Reproduce the issue
pot_not_honored.zip
pot_not_honored.potas the source template for new translations(why isn't it suggested automatically? The .po file(s) are detected)
Expected: two strings, four words as in English, 50% translated.
Files -> upload translation
Extract
pot_not_honored.potfrom the zip and upload it again with "update source strings"IMHO the .pot file should always be the reference for the translations. It may well be that .po files haven't been updated for a while and thus are missing msgids or containing outdated msgids. The attached .zip only tests the first case, not the second.
The text was updated successfully, but these errors were encountered: