Makes sense to me. Could be prototyped with a gadget too.

I’m not sure if JS-less experience should be a priority here. We promise that (in fairly recent browsers) things can be done even without JS, although they may take a few more clicks. This is exactly the case here: if it doesn’t work without JS, the user needs to continue to go through the list manually and tick the checkboxes one by one. No functionality is lost, it’s just some inconvenience. This is similar to the Select: All, None, Invert links (for editing change tags) at the top of a page history, they also don’t work without JS.

Option 1 - Simple JavaScript only

To keep things simple, we could add a link Toggle invalidation through JavaScript right under the heading New and existing translation units. This link will not be added if JavaScript is disabled. Clicking this link would either select or deselect the Do not invalidate translations checkboxes.

No back-end change is necessary.

Option 2 - More elaborate implementation, that will work without JavaScript

We can add a new checkbox: Do not invalidate translations for any translation unit. If the user selects this checkbox, on the server side we can update the code to not mark any translations as fuzzy / invalidated.

Additionally, we could add JavaScript code that would select all the Do not invalidate translations checkboxes when the Do not invalidate translations for any translation unit checkbox is selected. If any of the checkboxes with Do not invalidate translations is then un-selected, the Do not invalidate translations for any translation unit would also be un-selected. This code can be added in the existing: ext.translate.special.pagetranslation.js file.

We would still want to do the server side check to have the functionality usable even if JavaScript is disabled.

Screenshot of how this could look:

@Pginer-WMF - Thoughts?

In T298852#7671296, @abi_ wrote:

@Pginer-WMF - Thoughts?

Thanks for the context, @abi_
If I'm interpreting the above correctly, this could be a schematic representation of the proposals:

From my perspective there are two aspects that may be worth considering:

• Given that there may be several units, adding UI controls to each of them may result into many repeated elements. If those are only needed in very specific cases, it may be worth showing them only in such cases.
• The concept of "not invalidating the translation" was a bit hard to interpret immediately. It may be worth exploring concepts that could be more direct (avoiding double negation) and help anticipate the effect of the change.

Below you can find a possible application of the above ideas where checkboxes only appear after the user shows the intent to make a non-standard selection, and presented the question in a positive way (require a new translation):

Also, a more verbose version:

In T298852#7689181, @Pginer-WMF wrote:

the question in a positive way (require a new translation)

Invalidating the translation doesn’t mean that it requires a completely new translation; if a completely new translation is needed, a new translation unit should be created so that readers are not confused until the translation is updated (which may take years if it happens at all). Invalidating means that there are some changes in the source text that need to be reflected in the translation, but it’s not completely replaced with something else. For this reason, I’d rather say “require updating the translation” (or something similar). However, please notice that you silently changed the meaning of the checkbox: checking “require updating the translation” means the same as NOT checking “Do not invalidate translations”. If the meaning of the checkbox is changed, the old wording also becomes singly negated, “Invalidate translations”.

In T298852#7689340, @Tacsipacsi wrote:

In T298852#7689181, @Pginer-WMF wrote:

the question in a positive way (require a new translation)

Invalidating the translation doesn’t mean that it requires a completely new translation; if a completely new translation is needed, a new translation unit should be created so that readers are not confused until the translation is updated (which may take years if it happens at all). Invalidating means that there are some changes in the source text that need to be reflected in the translation, but it’s not completely replaced with something else. For this reason, I’d rather say “require updating the translation” (or something similar).

Thanks for the feedback. I see how the "require a new translation concept" can be confusing. I've explored how it works to use the concept of “require updating the translation”:

However, please notice that you silently changed the meaning of the checkbox: checking “require updating the translation” means the same as NOT checking “Do not invalidate translations”. If the meaning of the checkbox is changed, the old wording also becomes singly negated, “Invalidate translations”.

I think we can make the checkbox have the meaning that has the most direct interpretation. For "invalidate translation" it may convey the idea of doing a special action when it is the default expected behaviour. Users not familiar with the internals may react with caution on actions that seem destructive (invalidate, delete, etc.).

I show below a comparison for the same interaction idea but using different concepts to facilitate comparison: requiring update (what translators will have to do), mark as outdated (what translators will see as the result), and invalidating (the technical action).

Require updates	Mark as outdated	Invalidate

Sometimes I replace the old tvar format <tvar|1> with the new one <tvar name="1">.

Since T52103: "Do not invalidate translations" checkbox at [[Special:PageTranslation]] should be checked by default if change does not require updating translations, this kind of changes is automatically defaults to not invalidating translations, and I can’t think of other common cases in which it’s preferable not to invalidate any translations. I’m not to say this feature shouldn’t be created, but its impact will probably be quite limited.

Change #1057848 had a related patch set uploaded (by Huei Tan; author: Huei Tan):

[mediawiki/extensions/Translate@master] Add "select all" function for nofuzzy choosebox in Special:PageTranslation

https://gerrit.wikimedia.org/r/1057848

@Pginer-WMF the "Allow translation of page title" will be under General Area? or should it move to above bottom? let me know if the current view looks fine

In T298852#10034483, @hueitan wrote:

@Pginer-WMF the "Allow translation of page title" will be under General Area? or should it move to above bottom? let me know if the current view looks fine

Yes. I think "Allow translation of page title" makes sense as part of the general area.

Change #1057848 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] PageTranslationSpecialPage: Add "select all" function for nofuzzy choosebox

https://gerrit.wikimedia.org/r/1057848