@ppelberg - Any thoughts on this? I think switching a wiki while editing is a valid, although most likely rare use case. That said, I don't have strong thoughts behind getting back to parity.

In T285973#7208386, @ovasileva wrote:

@ppelberg - Any thoughts on this? I think switching a wiki while editing is a valid, although most likely rare use case. That said, I don't have strong thoughts behind getting back to parity.

While I appreciate the value in having access to version(s) of the article you are editing in another language (e.g. to see if there is a discrepancy in sources between the two versions, as @Daehan mentions), I would not be comfortable providing that functionality by way of enabling the language selector as it's currently implemented without first understanding what people who are newer to editing would expect the language switcher to do.

Reasons:

• The previous experience [i] (assuming I understand it accurately), offers this functionality outside of the editing interface. As such, I am assuming: A) people not seeking out this functionality are not likely to notice/engage with it and B) those who do end up engaging with it will expect doing so to "take them away" from the changes they are in the process of making.
• By enabling the language switcher within the editing interface, at the top of the page, I assume more people are likely to notice and engage with it. Without us knowing what these [potentially] unsuspecting people understand this functionality to do, I have concerns about displaying it so prominently.

As a result of the above, it seems like the need remains for people to be able to see and access the versions of the article they are editing in other languages while they are editing and it is to be determined where and how that need is met (e.g. somewhere within the editing interface, somewhere outside of it as had been the case previously, etc.)/

i. Previous experience: before the new language switcher was introduced, someone who was wanting to see A) what other languages the article they were currently editing exists in and B) the contents of said articles, they would need to do the following

• Desktop: A) view the languages listed in the In other languages section within the page's sidebar and then B) click the link of the language to see the version of the article they are editing in said "language."
• Mobile: functionality for "A)" and "B)" does not exist.

We disable everything that's not article-content that's inside the editing-surface, because we think it's confusing to have non-editable things inside the editor -- particularly links.

E.g. if I'm editing the article and click on the language switcher inside the editor UI and choose another version of the article, am I expecting it to:

• Switch the editable-content in-place so I'm now editing the other version of the article
• Discard the current edit and navigate to the other version <-- closest to the not-editing behavior, but probably not what anyone actually wants...
• Keep the current edit and navigate to the other version in a new window/tab

(The argument for why the sidebar-version was less prone to this is that there's more of a conceptual separation when the link you're using is outside of the editor chrome.)

All that said, it wouldn't be terribly technically difficult to just exclude the switcher from the disabled elements, if we're okay with the way it'll behave.

I agree with the request. Interlanguage links have been accessible in visual editing and in source editing for many years, and they must remain accessible.

In T285973#7230768, @DLynch wrote:

We disable everything that's not article-content that's inside the editing-surface, because we think it's confusing to have non-editable things inside the editor -- particularly links.

This was many years before Desktop improvements, so there was no intention to include interlanguage links in it. They just happened to become inaccessible now because they moved next to the title.

In fact, for quite a while the title was visible, but not clickable, and there were complaints about this, because sometimes wanted to highlight and copy it. It was eventually made clickable (still grayed out, but AFAIK, no one complains about that).

E.g. if I'm editing the article and click on the language switcher inside the editor UI and choose another version of the article, am I expecting it to:

• Switch the editable-content in-place so I'm now editing the other version of the article
• Discard the current edit and navigate to the other version <-- closest to the not-editing behavior, but probably not what anyone actually wants...
• Keep the current edit and navigate to the other version in a new window/tab

I suspect that there is some overthinking here :)

If the language selector is at the same place, and looks identically while reading, while editing wikitext, and while editing visually, it's sensible to expect that it would perform the same thing, too.

(The argument for why the sidebar-version was less prone to this is that there's more of a conceptual separation when the link you're using is outside of the editor chrome.)

True, but again: I don't feel that it's a problem. User research may prove me wrong, but for now I'd say it's safe to assume the above: if it looks the same, it does the same thing.

The button could open visual editor's "Languages" dialog (currently accessible only from the hamburger menu). This would be similar to how clicking the categories at the bottom of the page opens the "Categories" dialog.

Then we could improve the dialog to have links instead of page titles, which would resolve this task.

From an editor's experience. Now I have to get used to open two other language versions before I click the edit button, so I can change to there to look-up for something (i.e. references or images) and I have those tabs open all the time. Because now opening tabs while editing is impossible and because opening new tabs with the new language switcher is way more time-expensive.

So yes, the language switcher should be available when we are editing.