Translations for strings added in Weblate get reset shortly after creation #8074
Comments
|
Have you checked whether the translation is written to the file? |
|
I can't remember if we ever had a look between "translations are created" and "entries have been reset", but after the entires have been reset, only the main file (Resources.resx) contains the new strings. Resources.fr-ch.resx and Resources-it.ch.resx do not contain the new strings. It's how we found out about the issue, mostly - by having PRs that weren't "balanced" (i.e. had multiple new strings in the main language, but none in the translations, which given our workflow shouldn't happen). |
|
The string should be added to the translation files once it is translated. Going again through the original report, are you confident that it happens without the resx update add-on? To me, this looks the most likely way of introducing such bug (though, I still didn't manage to reproduce it). |
|
I've added the resx add-on as a failed attempt to fix the issue. I've added the squash add-on at some point (although I believe the issue happened before already - just in two separate commits, one adding it, one removing it?), and the resx later on. I'll happily try whatever you suggest. I've tried to reproduce it with my local installation, but couldn't trigger it, no matter what I tried - even with the same docker config. Even on the server itself, it's not guaranteed to revert. I'll remove the resx add-on for the time being. I don't know how weblate internals work, but if it's a timing issue (i.e. around the time some daily task runs), it could be possible that the usual work hours just collide really well with that. I suppose I could take a look at the recent changes and see when a previous populated field is wiped without an user and see if a pattern emerges. |
|
Any update on the repository is performed with a lock held, so it should not be a concurrency issue. It could be an ordering issue - the new string is added to the source, it triggers commit, what might trigger resx add-on (it should not, it should happen once all pending changes are committed), which adds empty string. This could explain overriding translated pending string. Still, I could not find reproducer for that... |
|
Yes, it seems hard to reproduce it. It's not guaranteed to happen even on the prod system where it does seemingly all the time. However, it just happened again, and I had the resx addon uninstalled. This is the latest one: Looking at it like this, it seems like adding another string could trigger this behaviour? Roughly:
I'm sorry if this is total nonsense because I don't know how weblate works, internally, but could it be that adding another string triggers an update of the main file/language, which then resets the other translations? |
|
Got similar problem with "Cleanup translation files" plugin I use selfhosted weblate 4.14 and gitlab integration via ssh
Should I create new issue? |
|
Can you reproduce the issue without the add-on? It seems we might have issue with add-on execution, as that would explain such behavior. |
|
i cannot reproduce w/o addon anyway i'll try to describe reproduction steps on next weekend |
|
The only add-on we're still using is GIt squash to keep the git history somewhat short-ish. I've disabled it temporarily to see if that helps (or at least makes it more obvious what is happening). |
|
#8113 might address this issue, I would appreciate if somebody could test whether it really does (I didn't yet manage to reproduce the issue). |
|
Closing, this with assumption that #8113 will address this in the 4.14.1 release. In case it does not, please let me know. |
|
Thank you for your report; the issue you have reported has just been fixed.
|
Describe the issue
When creating a new string in a component backed by monolingual resx files and translating it into other languages using Weblate, it sometimes (frequently?) resets the translations back to an empty string a while after its creation. The original string is not changed during all of this.
This seems to only happen once after creation, which makes me believe that it might writes the new strings into the base file, then reads the base file, sees those new strings, and gets a bit confused about it.
The remote repository is only written by weblate. There was no change by a developer that did not happen over Weblate. In our setup, we're using Weblate exclusively to manage translations, and the repository itself also only contains translations (plus the minimum boilerplate to use it in our application).
I've taken the liberty to anonymize the project, component and string names, as well as URLs and translations in the logs below.
The complete changes.csv for the day, showing two occurrances (for text1 and text2):
If we take for example the first string:
WEBLATE_LOGLEVELis set toDEBUG, but there's nothing that I could find that explains the behaviour. All log times here are UTC+2 (... for some reason). These are the docker logs, minus heartbeats, from 14:57:16Z until 15:00:16ZI already tried
Steps to reproduce the behavior
This is the steps to re-create our setup - because it's occurring all the time, but not really reproducible on-demand:
Expected behavior
Weblate does not reset translations by itself.
Screenshots
Exception traceback
No response
How do you run Weblate?
Docker container
Weblate versions
Weblate deploy checks
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: