The Translate extension should use the correct hook for providing edit notices (https://www.mediawiki.org/wiki/Manual:Hooks/TitleGetEditNotices) then this should work as expected.

Note also that the current hook expects to be able to load style modules for these "edit notices" (specifically ext.translate.quickedit), whereas real edit notices don't let you load modules.

Change #1018246 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/Translate@master] Add edit boxes as real edit notices

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

These are not edit notices. They are legacy UI that we have kept around.

We have explicitly disabled VE for translation: https://gerrit.wikimedia.org/g/translatewiki/+/1937e7ac1c3e3731aa381b2a30910a0a2db03a4c/mw-config/TranslatewikiSettings.php#254

Why do I have visual editor buttons on translatewiki.net in those namespaces then? (And what would be the problem with keeping it?)

I think trying to make VE and Translate extension work together on those pages specifically is worthwhile. This way small typos can be fixed more easily by translators.

As @jhsoby pointed out https://www.mediawiki.org/wiki/Extension:VisualEditor#Changing_active_namespaces says we should use namespace names instead of ids (why? everything else uses ids). Maybe we didn't test this change properly.

But I'm confused though by code like https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/e49b10bcef95f209758a0d85ab8de152ad891e2c/includes/Hooks.php#120 that adds namespace ids to the list. Is that code wrong. @Esanders?

In T362125#9700720, @Nikerabbit wrote:

As @jhsoby pointed out https://www.mediawiki.org/wiki/Extension:VisualEditor#Changing_active_namespaces says we should use namespace names instead of ids (why? everything else uses ids). Maybe we didn't test this change properly.

I found that information via this topic on mw:Extension talk:VisualEditor, which is the top Google hit for "wgVisualEditorAvailableNamespaces". The last comment by kghbln linked to a thread on the now-defunct discourse-mediawiki.wmflabs.org, and I just edited the link to point to an archived version. In there, kghbln points out something interesting: You can add namespaces to wgVisualEditorAvailableNamespaces using the ID (or constant), but to remove them you have to use the English canonical name.

Which would explain why this code is working even though it's using the ID instead of the canonical name:

But I'm confused though by code like https://gerrit.wikimedia.org/g/mediawiki/extensions/VisualEditor/+/e49b10bcef95f209758a0d85ab8de152ad891e2c/includes/Hooks.php#120 that adds namespace ids to the list. Is that code wrong. @Esanders?

Test wiki created on Patch demo by Tacsipacsi using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/1f6668b3c1/w

I’ve created a patch demo. I thought the edit notice would be awfully long, but it’s actually not that bad (log in with Patch Demo / patchdemo1 and open https://patchdemo.wmflabs.org/wikis/1f6668b3c1/wiki/Translations:Main_Page/1/en?veaction=edit or https://patchdemo.wmflabs.org/wikis/1f6668b3c1/wiki/Translations:Main_Page/1/hu?veaction=edit).

However,

• Prepending !!FUZZY!! doesn’t work, so translators have no way to see that the translation they’re editing is outdated so they should compare it with the original (but I assume saving the page would remove the fuzzy marker, causing the outdated translation to go unnoticed for a long time).
• VisualEditor and the Translate/MediaWiki message syntax are not really compatible. For example, in the English version, there is the wiki code [$1 '''Patch demo'''] – a link whose URL is a translation variable. VisualEditor doesn’t recognize it as a link.
• And, of course, the styles are missing.

Is there any way to differentiate page-wide translations like MediaWiki translations from these translation units translations? Because making Translate extension compatible can be limited to page-wide translations then so there’s less confusing code.

Regarding !!FUZZY!!, I think this is a more general issue with Translate extension. See for example this edit: https://translatewiki.net/?diff=12345686 — I think !!FUZZY!! was there at some point and I only ended up seeing it because I went into source code mode afterwards to edit yet again, but nothing was shown upon saving. There might be some other cases where that’s true.

In T362125#9702016, @stjn wrote:

Is there any way to differentiate page-wide translations like MediaWiki translations from these translation units translations? Because making Translate extension compatible can be limited to page-wide translations then so there’s less confusing code.

Page translation translation units (this is what you call “translation units translations”) are in the Translations: namespace, MediaWiki messages are mostly in the MediaWiki: namespace. However, both use similar syntax (I think the only difference is that MediaWiki message variables names are numeric while page translation supports almost any characters in variable names), so I don’t think limiting VE to only one of them makes sense. (Although it still makes more sense than in some other namespaces of translatewiki.net: message groups like Wikimedia mobile apps, OpenStreetMap or MantisBT aren’t even wikitext.)

In T362125#9702026, @stjn wrote:

Regarding !!FUZZY!!, I think this is a more general issue with Translate extension. See for example this edit: https://translatewiki.net/?diff=12345686 — I think !!FUZZY!! was there at some point and I only ended up seeing it because I went into source code mode afterwards to edit yet again, but nothing was shown upon saving. There might be some other cases where that’s true.

A message can become fuzzy in three ways (if I didn’t forget anything):

• The original-language message has been changed. This is the most common situation. This is set by translation admins on special pages (they can decide whether the change in the original-language message should cause the translations to be fuzzied, so that e.g. a simple typo fix in English doesn’t require extra work from translators), i.e. outside of the translator’s editing session.
• Someone manually prepended !!FUZZY!! to the message (or the legacy edit form loaded with !!FUZZY!! prepended and the editor haven’t removed that). This also happens outside of the (next) translator’s editing session.
• The translation contains some error. This happens within the translator’s editing session, so immediate feedback helps avoiding it. Special:Translate warns the translator before saving (it runs some checks with AJAX requests), but this functionality isn’t built in the legacy editor. Since the legacy editor is legacy, I’m not sure if someone wants to put work into implementing (and maintaining!) it there.

The link you shared is the third case (the [[Special:Preferences#mw-prefsection-gadgets]] link was missing, which is considered an error in MediaWiki message translations).

Change #1019044 had a related patch set uploaded (by Jon Harald Søby; author: Jon Harald Søby):

[translatewiki@master] Remove MediaWiki namespace from $wgVisualEditorAvailableNamespaces

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

Change #1018975 had a related patch set uploaded (by Winston Sung; author: Winston Sung):

[translatewiki@master] Fix use of $wgVisualEditorAvailableNamespaces - attempt 2

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

Change #1019044 abandoned by Jon Harald Søby:

[translatewiki@master] Remove MediaWiki namespace from $wgVisualEditorAvailableNamespaces

Reason:

Already submitted here: I50ee1bbc0b95b90f1b6522fa2989e84d95b527cf

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

Change #1018975 merged by jenkins-bot:

[translatewiki@master] Fix use of $wgVisualEditorAvailableNamespaces - attempt 2

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

I think we shouldn’t give the impression that VE is supported (by showing the edit notice) before fuzzy messages are marked at least as visibly as in the wikitext editor, because it’s now broken without the breakage being obvious. (Not supporting translation variables is another thing: it’s broken in an obvious way, so users are able to decide if they want to use VE regardless.)

‘At least as visibly as in the wikitext editor’, or... not so much :-) I don’t see why the deficiencies of Translate extension in that department should preclude from fixing this task.

Change #1018246 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] Add edit boxes as real edit notices

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

Because, as I said, it gives the impression that VE is supported – an impression that couldn’t be further from the reality. It’s not only unsupported, it’s known to be broken.

If someone opens a message in VE, fixes a typo and then saves it, the record of the fact that the translation was – and continues to be – outdated is lost. Completely. The fuzzy flag is deleted from the database, with zero traces left. The message doesn’t appear in the list of outdated translations anymore, the !!FUZZY!! prefix (legacy wikitext editor) / yellow warning bar (Special:Translate) doesn’t appear anymore, the diff showing the changes in the original message doesn’t appear anymore. The only way the translation will ever be fixed is that a human finds it by chance, for example when browsing through all translated messages, or by seeing the same message in two languages (e.g. in two wikis) and noticing the discrepancy – both of these are pretty unlikely.

We are actively disabling VE on translation namespaces. Can't do much about people who will use VE on them anyway.

What you are describing are deficiencies in Translate extension, not in VE. Same would probably happen if I use https://en.wikipedia.org/wiki/User:BrandonXLF/QuickEdit if the handling of !!FUZZY!! is really so fragile. That should be fixed instead of trying to break VE support for no reason.

In T362125#9720129, @stjn wrote:

That should be fixed

I agree. Do you have any ideas how could it be fixed?

instead of trying to break VE support for no reason.

I didn’t propose actively breaking support. I proposed not seemingly starting to support VE as long as we don’t really support it.