Why would you want to edit languages, in order to understand the problem that you report here? To add links to articles with the same topic in other languages? That is exactly what Wikidata is for.

With regard to the wheel "which opens something else", this is part of your language and input text settings.
See http://www.mediawiki.org/wiki/File:ULS_Usability_testing_summary.pdf for the Usability tests that led to this design.

to really edit the languages one has to go to page settings!

I cannot find anything called "Page Settings" on for example http://en.wikipedia.org/wiki/Berlin . Please provide exact steps to reproduce.

page settings at the right

Attached:

wikidata at the bottom

attached page settings at the right, with languages. and wikidata at the bottom. and i see, you do not know this beast as well and do _not_ expect the language code there. just remove this language link code and all people are happier.

Attached:

i see, you do not know this beast as well

I admit I don't know every single option of software running on Wikimedia servers by heart, plus sometimes bug reporters paraphrase things. That's why I appreciate good steps to reproduce to understand the problems that you're facing.

Now that I can reproduce I agree that it's slightly confusing.
However the bug summary does not describe the problem but one potential solution, hence changing the bug summary to:
"VE > Page Settings > Languages" functionality expected where ULS' "Language Settings" cog is

and all people are happier.

On a general note: If you have not run a survey in your neighborhood and beyond (as other neighborhoods might have different needs and expectations), generalizations feel like http://en.wikipedia.org/wiki/Wikipedia:WEASEL and might diminish the impact & interest in your suggestions how to improve Wikimedia, which would be a pity.

Being able to edit language links is bug 52105 (specifically, for Wikidata ones). This would replace the current hacky gadget.

The other part of this bug (about the cog not letting you change settings of other languages) would be an issue with ULS, not VisualEditor, I think?

james, bug 52105 is the exact opposite of the suggestion here. the visual editor team should, imo, leave the hacky gadget, or improve the hacky gadget with something which is not called hacky any more.

and, _remove_ the code to edit language links from the already complicated VE.

(In reply to comment #6)

_remove_ the code to edit language links from the already complicated VE.

There is no code to edit language links in VisualEditor. What are you talking about?

oh, you are right, it is just code to parse and display it in page settings *blush*, sorry for confusion. coming back to the original suggestion: why not improve the hacky gadget in the frame of the VE project, instead of including it in the VE?

the "about the cog not letting you change settings of other languages" and "ULS" i did not understand. what would you mean by this?

"about the cog not letting you change settings of other languages" refers to the small wheel symbol in the side bar close to "Languages".
It is created by the MediaWiki extension "UniversalLanguageSelector" (ULS) so that would be the codebase to change for that aspect, not VE's code.

(In reply to comment #8)

oh, you are right, it is just code to parse and display it in page settings
*blush*, sorry for confusion. coming back to the original suggestion: why not
improve the hacky gadget in the frame of the VE project, instead of including
it in the VE?

The hacky gadget, as I recall:

• Doesn't let you set non-Wikidata language links (as needed on non-Wikipedia wikis)
• Doesn't let you set local language links to over-ride the ones from Wikidata (as needed on Wikipedia sometimes e.g. for [[Maggie Simpson]])
• Doesn't let you change/remove other languages' links without making you leave the site and going to Wikidata to use the tools there
• Doesn't let you create new Wikidata entities for the page
• Is based on local code that may differ between wikis (making VisualEditor work differently in different places)

We agreed with the Wikidata team a few months ago that replacing this was a worthwhile thing to do.

Incidentally, on the wider point, we're very keen to start moving away from editing being a monolithic block of actions that have to take place together, and instead letting users "curate" quickly - whether that's changing categories, language links, workflow action items (like "needs wikifying" or "nominate for deletion") or other tasks - without having to enter the editor.

HOWEVER, that's not really the point of this bug, is it?

my english is not good enough to understand the "incidentally, ..." paragraph. what does that mean in terms of coding?

(In reply to comment #11)

my english is not good enough to understand the "incidentally, ..."
paragraph. what does that mean in terms of coding?

We may write more code to let you use bits of VisualEditor (like the dialogs) outside of the editor.

Sorry, I meant to move this to ULS (as it's mostly a ULS design question) when it was filed some weeks ago.

This is generally a valid feature request, and this is something that ULS and VE developers should consider some time in the not-so-far future.

I've updated the task description with some background information.

The main thing I'm unsure about is why the cog is placed near the "Languages" sidebar section. Especially given we already have two other interfaces for editing the user language. Do I understand correctly that the intention is to (eventually) migrate all wikis away from the "cog" icon in favour of the ULS dialog trigger from the personal tools? The dialogs have different designs, but seem similar in purpose. And I can't actually find a wiki/page combination that shows both, which leads me to believe it is a configuration option, of which the personal-tools placement seems preferable as it avoids confusion with the purpose of the "Language links" sidebar section.

Can someone confirm this? And/or point to a roadmap of some sort related to this?

In T54383#4015867, @Krinkle wrote:

The main thing I'm unsure about is why the cog is placed near the "Languages" sidebar section. Especially given we already have two other interfaces for editing the user language. Do I understand correctly that the intention is to (eventually) migrate all wikis away from the "cog" icon in favour of the ULS dialog trigger from the personal tools? The dialogs have different designs, but seem similar in purpose. And I can't actually find a wiki/page combination that shows both, which leads me to believe it is a configuration option, of which the personal-tools placement seems preferable as it avoids confusion with the purpose of the "Language links" sidebar section.

Can someone confirm this? And/or point to a roadmap of some sort related to this?

The different ways in which language selection is provided are the result of trying to keep a single area related to language where the default selection is about content (plus backwards compatibility). I'll try to elaborate and add some context:

Our goal and what we learned about the user needs

We want to provide the ability to select both, the content language and the UI language. During our user research we identified that many users don't have a very clear distinction of both concepts (or don't make a careful evaluation on which part a language selector they find is going to change). The most common expectation was to change the content (or both, content + UI). That is, if a user finds a selector with a list of languages and selects Italian, the user expects the content of the page to become in Italian, and it would be unexpected to see that only a few menus (the UI) change to Italian instead.

Based on the above, we tried to follow the guideline of presenting the option to change the UI language in a less prominent way than the content language selection. That is providing a default selector for changing the content language, and less prominent advanced options in case you wanted to specifically change the UI only.

Why there are two different solutions

We had two different kinds of wikis. Some wikis are multilingual, like Commons. Other wikis are a group of individual monolingual wikis linking to one another, like Wikipedia in each language. For multilingual wikis we presented a language selector on the personal toolbar on top. The selector let's you pick the content language and provides advanced options at the bottom to change other aspects such as the UI language. This was working well, and having the language selection on top was easy to discover.

However, monolingual wikis had already an established way to change the content language (technically, to jump to the equivalent page in a wiki of a different language) using the interlanguage links. At that time, we decided to keep the interlanguage links to avoid pushing for too much change at once (although we may want to revisit that in the future). With the constraint of keeping the interlanguage links where they were, placing the UI selector on top was problematic because (a) it created two separate areas for language selection, and (b) the most prominent one (on top) was not about content but UI. So we decided to have a single area dedicated to languages, keeping interlanguage links where they were as the most prominent language selection, and provide advanced options in a less prominent way as advanced settings.

Little comment 1: Since the task was filed in 2013, another element was added to most pages near the languages in the sidebar: "X more", opening the compact language links panel. I am adding the ULS-CompactLinks tag here, because even though this project didn't exist when the bug was filed, it is totally relevant in the context. I am also adding the Wikidata tag, because it has a lot to do with it.

Little comment 2: The following two tasks at least partially overlap with this one:

1. T53355: Feature request for VisualEditor language setting +ULS +Wikidata interwikis
2. T53431: Mingle Wikidata interwiki links with ULS to choose display and input while visiting the link itself

So, we now have two or three elements near the languages list:

1. The cog, near the "Languages" title:
   • Coming from the ULS extension. Used for choosing UI language, and configuring webfonts and keyboards. It was put there back in 2012 when the first version of ULS was developed. Of course, the association between the "Languages" title, familiar to most wiki editors (and possibly to many readers) was a factor in choosing this location.
2. The Wikidata link at the bottom:
   • It has the text "Add links" when the page is not linked to versions in other languages. Clicking it opens a dialog for adding the links without leaving the page.
   • It has the text "Edit links" when the page is linked to versions in other languages. Clicking it goes to the item page in Wikidata.
3. The Compact Language Links "''X'' more" button:
   • Appears only on pages with 9 links or more, and only if the Compact Language Links preference is enabled. (It was in beta for a long time, but now it is default in Wikipedia in all languages, and in most other Wikimedia projects.)
   • Clicking it opens a ULS panel with all the languages in which the page is available.

This is not ideal.

This is not ideal for a lot of reasons:

1. Generally, three elements near the language the list feel like a bit too much.
2. The cog is at the top, but the things that it includes are probably needed by fewer people. I'm saying "probably", because I don't have the numbers, but we can try to obtain them. Fonts and keyboards configuration is important in some languages, but completely unnecessary in a lot of others (at least in the current implementation; I have a lot of ideas for redoing webfonts support, but they are far from being implemented, and they are way beyond the scope of this task). One thing I'm sure of is the the other two elements are needed by users in wikis in all languages, and the cog—only in some.
3. The language selector in "Display settings" under the cog includes all the languages, but it only selects the UI language. Even though the panel explicitly says what does it do, I suspect that some people—possibly a lot—select the UI language instead of the article language. I've seen it happening to a lot of people in workshops for new editors.
4. As a follow up to the previous point: Changing the UI language is not currently available to logged-out users. The panel says so, and some people may even think that they can only read an article in another language if they log in. It may sound crazy, but it may be true.
5. The title is not always actually "Languages". It is "Languages" in some wikis, but in others it is "In other languages", "This page in other languages", or something else.
6. "Add links" and "Edit links" have the same location, but different text, and completely different behavior. I suspect that a lot of editors will appreciate editing wikidata sitelinks (i.e. languages) in a dialog similar to the one that is used for initial linking, thus making the functionalities similar. I've been hearing comments like this from a lot of users in a lot of languages for years.
7. This is more of a guess than the previous point, but I further suspect that a lot of editors will appreciate a link to the Wikidata item page in a convenient location, possibly near the language list. "Edit links" is such a link already, but that's not what its title says. There is also a "Wikidata item" link buried elsewhere in the sidebar, which does largely the same thing. As an editor, it's one of the very few sidebar links that I actually use, although I might be very different from a lot of other people. This requires proper research.
8. The "''X'' more" button appears in some cases, but not always.
9. The language selector (ULS) and the language editor (WikidataClient's dialog) are related in their functionality, but they have a completely different interface design. It would be nice to bring their appearance closer to each other.

That's a lot of different issues. There's material here for a lot of different tasks and subtasks. Fixing them is desirable. It won't happen overnight, and it will require proper design work, and not just editors' or developers' intuition. It will probably require collaboration between Wikidata developers and WMF's Language team developers.

But yes, it's about time to start resolving it.

To @Krinkle's question—no, there's no proper roadmap at the moment. This very long comment is, hopefully, the first attempt to think of such a roadmap.