Source strings needing work locks all translations

[comradekingu]

Describe the issue

If for whatever reason the source string is marked as needing work,
it means all translations thereof are locked.

This means no other issues in the translate to-languages can be fixed meanwhile.

I already tried

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

Steps to reproduce the behavior

0. (Source string is marked as needing work.)
1. https://hosted.weblate.org/translate/hedy/web-texts/nb_NO/?checksum=1636e86e15277e57
2. Can't edit in nb_NO

Expected behavior

Would expect all translatable strings to be editable.

Screenshots

Here it should be "E-post-oppsettsveiviser"

Exception traceback

No response

How do you run Weblate?

weblate.org service

Weblate versions

No response

Weblate deploy checks

No response

Additional context

Also, https://hosted.weblate.org/translate/ubports/app-dekko/nb_NO/?checksum=40f7a65819757880

As a rule I want to correct the mistakes of others and myself when I am able to, and not on the assumption that
the source string is always the issue.

As long as the string is used, it at least removes insult from injury.
It is better to have a correctly typed string rather than one that is wrong and badly mistyped.
If that removes the "needs work" in the translated to-language, it is a problem with having one
checkbox.

Just the one checkbox creates similar issues when there is assumptions made over what the original error was, and its correction.

I think having it editable now, and then also possibly notifying all people adding "needs work" that their issue was attemptedly fixed is a good quickfix.

[nijel]

This is intentional, if somebody is going to rewrite the source string, the translations will need to be fixed after that anyway.

[comradekingu]

Mistakes in source strings don't always propagate to the translation though.
Similarly, it is possible the string just needs an improvement, that isn't obvious to anyone.
Moreover, it can also be that the fix is obvious.

Lets say the source string is "Url" when it should have been "URL". (It happens X)

Someone could fix that in their own language, and logically go to the source string to mark it as needing work.
Except it isn't at all explained that this locks the string for everyone else.
So someone else can come and toggle the source string needing work only to be able to fix it in their own language.
This sends more e-mails to the admins than they strictly need.

Or fix it in all translated languages, and then mark as needing work for the source? That locks all new languages.

So what problems are buried here?
I have thousands and thousands of strings marked as needing work in nb_NO when the problem exists in the source string for this reason.
Now it is functionality I rely on others not undoing for actual nb_NO mistakes, when I use it for even other things.

Does the platform want to facilitate quality, or try to minimize the amount of actual work done?

From my point of view I want to fix things when I am there, not down the road.

I'd rather take the marked as fuzzy after an update when the string is correct for the user.
You get that more often with non-locking.

[nijel]

This was originally introduced for #3270. It might make sense to limit this to the workflow with intermediate translation only.

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

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