"Needs editing" change to "Needs rewriting" or "Needs checking"

[kyotarozzz]

Reason : "neeeds editing" remembers that it was automatically flagged when a new translation was added. I think there is a demand to flag translations that need checking later. Also, it is confusing to be a record that wrote a new translation even though only flags are attached.

Solution : Change the name of "Needs editing" to "Needs rewriting" or "Needs checking". Just select the check box and it will be recorded. This is enough.

Best Regards Kyotaro

[nijel]

It was changed to "needs editing" about year ago, see https://github.com/WeblateOrg/weblate/issues/1314 and https://github.com/WeblateOrg/weblate/issues/1616#issuecomment-326946263, I'd really like to come up with more acceptable name, but I'm not sure these two are actually better.

Maybe @comradekingu could share his opinion as well?

[comradekingu]

I think the problem is one term relating to many potential states. No one word distinguishes between them, but changing the one we have breaks every manual there is.

I would keep "needs editing" as a meta-category, but break it down into actual states.

What is now Needs work communicates either "upstream fuzzy", like XTM meaning the string changed and is now possibly outdated or "Translated tentatively", meaning the translator isn't 100% sure the translation marking something like this brings into question other strings of similar nature, but that is another matter. "Marked for review" is what that essentially is, and it should show up first.

"Reviewed" should be broken into reviewer. I want to know what I am sure about, not what someone else thinks. The only way a trust-system with many people does anything is knowing what strings to no re-review first. The threshold of when a string gets locked could be set based on amount of reviews, and then unlocking it could be a similar thing to avoid "drive-by translations". Some people care about stats, enough to cheat with them, so it should be "effective translations", and "accepted suggestions" or something to that effect.

(I really like the translatewiki way of just getting many different projects in the same editor, it also has a "review-mode", where the same is done for checking things. But that is also another matter.)

Another state a string can effectively be in is "source error", where an improvement to upstream string is likely to be found. There are many reasons for this, one of which is when a translator thinks something is wrong in the source. It would help upstream devs, or people that try to help out, or change upstream strings to know what these are. Right now many obvious source errors just get translated correctly. Another matter too, and it is all about speed. I think a checkbox would be fine, and then one could go back and add a reason later. Making it - "flagged as source error, but not explained".

I think the "another translation exists" should be system wide, and that one project should just be the various different strings, by complexity, sorted by frequency.

There the potential string variants are "auto-translated and no possible other way", (Like " or "pick one of many ways to translate this". Which takes the current "another translation exists" system wide. That would auto-populate many easy Android projects. It is also really handy to have, since it takes away a lot of grinding, and working on the list is little work for huge reward. Some platforms have auto-population, but it is always garbage on account of never being anything other than 100% or similar matching.

The current language specific checks could be expanded to find soft errors. "Global" is never a good string, and should instead be "System wide", or "For the whole program".

With the way English works, sometimes one word has a duality, like "hip" can either be a body-part or something fashionable. In this case the potential states are "Duality undecided", where an admin can pick which variant it is (and mark it with an (auto)comment to the string, or effectively "Duality fixed", where the autotranslation kicks in.

Then there are things best avoided, a group of English words or conventions that should just be avoided, "If untrue" or "If unchecked" being some of them. This could give admins or upstream translators something to work on, and it could be shown as a string-health bar for the project. Working on this goes a long way, since it has so much impact, and that it is currently so manual. It also would make Weblate a next-level platform.

Being able to change source strings from Weblate more often would really help too. You could even translate changes before a PR is accepted this way. This would be a "potential" string. Often on Transifex I get an e-mail about an issue being resolved, I check it, only to sometimes find it resulted in a PR. If that is good, all I can do is sit and wait till it lands, when I know what the downstream translation should be there and then.

I think translators could make better choices about what projects to translate and when if state-tracking was a thing. You don't have to translate anything to check whether an upstream change resulted in any downstream change, so that is a whole new class of people that can help out.

Maybe this makes sense, and maybe not: The type of fuzziness for an upstream string change sometimes obviously is one that wouldn't make it into a translation, in which case an admin could flag as "string typo", but that just lightens the load, and makes for something to sort the reviewing by.

[burner1024]

This is an easy local change, I don't see a need to push it on everyone. And I would certainly advise against adding more checkboxes or whatnot. Or at least, make them optional to display. I got people scared enough of Weblate's UI as it is.

[mesnevi]

At the moment "needs editing" flag is applied both for newly translated strings (which are not yet reviewed and can be machine-translated or awkward) and old strings (which source string was changed, thus all the translations need to be edited == fixed).

I suggest using "needs editing" for the latter case when an old translation was fine, and the changes need to be made to fit new source.

Probably there's a need for another flag for the new ones, something like "needs proofreading" or "needs a review". By the way, speaking of review (I'm sorry to turn aside from the main discussion), is there any way to find out for sure whether reviewing workflow is enabled in a particular project or not? According to docs, all the projects hosted for free do not have this option (i.e. reviewing is disabled). Does this mean that reviewing is not available for FOSS projects, say, like F-Droid?

[nijel]

The current "needs editing" indeed expresses several different things:

• result of fuzzy matching in Gettext
• result of source string change in Weblate for monolingual file
• translator made the translation but is not sure about that or somebody marks the bad translation
• translation was made by add-on by copying the source string

In all these cases somebody needs to look at the string and possibly do some fixes, that's why it was called needs editing. The question is whether we should differentiate these somehow in the UI. As it was already mentioned in some cases we're already providing too much options to users and this could make it even worse. The good think is that all these can be distinguished from Weblate POV without cluttering the UI with additional checkboxes - first two come from file updates, third ones when editing.

[nijel]

PS: The review process is currently opt in and is not available for free hosting. This used to be a technical limitation due to nature of permission system we've used, but now the limitation has stayed there for now.

[comradekingu]

I love that there is a "needs editing" that encompasses all those three scenarios. If there was a subsection with those three, it would be easier to click what i want, (for example fuzzies) rather than what i don't. (things I have marked myself).

Needs editing --- Changed upstream --- Translation memory match --- Marked

[mesnevi]

As it was already mentioned in some cases we're already providing too much options to users and this could make it even worse. The good think is that all these can be distinguished from Weblate POV without cluttering the UI with additional checkboxes

It sounds reasonable. I agree.

If there was a subsection with those three, it would be easier to click what I want

Probably it's possible to add some tags or flags to the source string in the code?

[burner1024]

If the translator is not sure, they ought to suggest it instead, no?

[comradekingu]

@burner1024 Suggestions are a whole other level of uncertainty. If a translation is within reason, it can be "Needs checking" and still be functional.

---

There are a lot of things that can be streamlined and simplified, whereas distinguishing between string states is not one of those things. One of the main problems is that everything is "Needs editing". If you want to keep track of upstream changes made, or possibly made, reported, and whatever problems the local component has, it is easy to loose track. Not to mention tackling a new issue on top of it all becomes impossible without sifting through everything manually.

I could keep largely untranslated projects from not getting worse, but now I can't, because there is no telling what is what.

[mesnevi]

If the translator is not sure, they ought to suggest it instead

I guess it's better to ask a developer for a context to clear tgings up or leave the string untouched.

I've seen so many lame or awkward translations caused by stat-hunters, some of them were directly copied from machine ones.

From the other hand, there are project when you cannot translate, only suggest, and this makes a story way longer.

Seems that there always be the need for human proof-reader, so 'needs checking' means 'requires attention, please check' and that's enough.

[comradekingu]

@mesnevi There isn't enough developer time for that, and even if there was, it would not cover a scenario of say, lacking a proper word to translate something into. The searching is a bit broken, so adjusting for consistency, it is an intermediate tool to work out what to check on the second pass. And that is if one person is doing all the translating. If someone drive-by -translates something, now it is unclear who did what, and who reviewed what.

One "Needs editing" isn't enough at all. If I solve my problem, all of a sudden I uncheck your issue, when you don't know what problem I had and vice versa. Worst case it is two different problems in one string.

Edit: Reporting people that machine-translate is cause for exclusion, regardless of fault-checking system. It is fairly easy to cheat the system by just uploading strings, which it seems like some people do, maybe for good reason.

[burner1024]

Suggestions are a whole other level of uncertainty. If a translation is within reason, it can be "Needs checking" and still be functional.

Well, how certain are you that other people's perception of level of uncertainty is going to align with yours? Because if it isn't, we're just muddying the water. I'm not sure what do you mean by unclear who did what, I believe string history is saved and available to view.

I don't understand how this is supposed to let know what the supposed problems were. All I would see is that someone marked the string. If the translation is good, but can be improved, it means that someone should review it, which calls for, well, review.

And if you got a rogue translator producing bad translations, no number of checkboxes is going to stop them. Only a proper review process.

[mesnevi]

@comradekingu

There isn't enough developer time for that, and even if there was, it would not cover a scenario of say, lacking a proper word to translate something into.

No need to dive into details. Just a couple of words, maybe a link, everyone translating is able to read wiki or simply google things he doesn't know or check some subject related articles in his native language.

I mean, the case when someone has no idea how to translate a technical term is not even worth paying attention to. I take it as suggestions are more about words order, or ideoms transition or fitting the style (in some languages like Russian words are very long, so making a good short description, which fits 80 signs limit, is sometimes a challenge).

Not sure about Crowdin, but it seems no one ever reads suggestions and source string comments on Weblate.

And, of course, the big problem is with different people having different schedules and attitude and unless you're in touch with them directly you can't rely on them fully.

Needs editing --- Changed upstream --- Translation memory match --- Marked

Subsections idea looks pretty neat. I do not use Zen mode, so I always see forms and check boxes. Are additional boxes really that obscure for the user?

[comradekingu]

@mesnevi There are automatic e-mails for suggestions on Weblate. On crowdin you have to click three times to send an e-mail to the creator.

Additional boxen need not be only in the main editor, in my view suggestions should be made from the same text-field, clicking to send with a different "suggest" button.

I want to only trust myself, which means staying on top of every e-mail change there is. Not only to know where and what I am working on, but also what other people are doing.

To me it seems nobody makes suggestions, because it harder than clicking in a translation that "Needs editing".

---

Here is one problem that arises. If you click "Needs editing", because the upstream source needs work, you have submitted a patch upstream and are just waiting for things to land. Now your perfectly fine translated strings, will not go in, because that is sometimes a setting for the project. Liberapay works like this, and it is horrible.

Also, right now it seems like

Needs editing (1) and "Failing checks (1)

Are two different things, when they are the same string. Needs editing:

• Failing checks

Would solve this.

[KadAnna]

There may be also other point of view - does the change, that triggered "needs editing", causes in error in the UI? I mean there is a difference if the source strings has been changed and therefore the translation needs to be edited, or if metadata have changed.

From the user cases I have come across, it is useful to distinguish which source strings have changed, as these prinarily needs the translator attention.

[nijel]

In some cases the distinction is clear - for example for monolingual files where Weblate can easily detect source string change. On the other side in GNU Gettext, it's not really possible to distinguish source string change from fuzzy matching - these both appear exactly same in the file.

Anyway the plan is to have more states indicating origin of the edit (source string change detected by Weblate / fuzzy matching coming from file / manually triggered by user). What is still being polished is the UI and therefore it's still unclear whether it will make it into 4.4.

[github-actions[bot]]

This issue has been added to the backlog. It is not scheduled on the Weblate roadmap, but it eventually might be implemented.

In case you need this feature soon, please consider helping or push it by funding the development.

[KadAnna]

another point of view: our translation agency applied different rate for new strings and for those that have been translated but needs some editing. Therefore, the status for "translation was made by add-on by copying the source string" is messing up statistics. See https://github.com/WeblateOrg/weblate/issues/2240#issuecomment-424332849