Tip: write and copy the canonical address to clipboard.

• Bug 17667 has been marked as a duplicate of this bug. ***

Using the clipboard provokes other problems. People are using the clipboard for many things. I don't want to additionally open a texteditor to cache the present clipboard to put "special:something" to clipboard and so on.

KDE already has a clipboard which can hold history of multiple entries and I
bet that similar are available for other system as well.

Not everyone uses his own computer. I use different computers, I'm not always able to choose an OS, I am not always administrator...
Wikipedia should be easy to use, whithout changing the OS and without installing additional software.

I'm trying to help you until we can find and implement a proper solution, if any. Let's not drag usability of MediaWiki (let alone Wikipedia) to this, remembering that this particular use case is not popular enough to force quick solution.

This could be done fairly easy by making $wgContLang English instead of whatever the content language is, right? Make it a user preference (somewhere at appearance->advanced options).

Afaik it shouldn't break anything, because there are aliases from English to ConentLang.

Anyway, it seems that the language system is in the middle of being rewritten (for 1.17.). Until it is ready, I won't touch anything :)

I'd go for wontfix - no need for more obscure user preferences and messing with $wgContLang sounds nasty.

mr.heat wrote:

The problem is: Things like "Special:Prefixindex" are IDs for that page (I know, there is an other numeric ID but this is not visible, what's visible is the ID "Special:Prefixindex"). IDs should not be translated.

This is similar to the translated function names in Microsoft Excel. Instead of "SUM()" or "AVERAGE()" you have to write "SUMME()" and "MITTELWERT()" in a German Excel. SUM and AVERAGE do not work at all. It's a mess. It's impossible to use an English help page while using a German Excel. However, it's possible to open an Excel sheet created in an other language. What happens is, Excel translates everything in the moment the file is opened.

Same here:

Solution 1: Do not translate "Special:Prefixindex" and other special page names. Make it "Special:Prefixindex" in all languages.

Solution 2: Do auto-translation (like Excel does). Lets say, if somebody calls "Spezial:Präfixindex" in the English Wikipedia it should be redirected to "Special:Prefixindex" or whatever this page is called in the targeted wiki.

The Excel-comparison doesn't cover all the way. The key difference is that Excel knows the language of the original document. So it's trivial to load that translation and map one to another.

If you go to https://nl.wikipedia.org/wiki/Spezial:Statistik is has no way of knowing that it's german. Because there is no original document or language code.

Meaning that it would have to scan all languages, which is currently not possible because of the following:

• Right now aliases have to be unique between all other aliases in that language and the canonical names. IF MW would go load and scan all languages, this policy needs to be changed technically that there may never be a collision between aliases even acros all languages.
• Last I checked there are a few special page that have a localized name in one language, while another special page has another localized name in some other language that is the same word. Languages have words that sometimes mean different things.

mr.heat wrote:

Then the solution is solution 1. Do not translate parts of the URI. For example, "action=edit" is not translated, "oldid=" is not translated. Same for "Special:Prefixindex" (and some other special pages), it should not be translated in the URI.

They are page names just like everything else, and we don't have all article names in English in different language Wikipedias.

mr.heat wrote:

(In reply to comment #12)

They are page names just like everything else

No, they are not as explained above. Why do you say this?

Why not to automatically add interwiki links to special pages? This way users could go to the section "Other languages" of the side bar and choose the appropriate language.

At least this is something which seems feasible in a user script similar to
https://de.wiktionary.org/wiki/MediaWiki:Onlyifsystem.js
which is a workaround for bug 708.

(In reply to comment #14)

Why not to automatically add interwiki links to special pages? This way users
could go to the section "Other languages" of the side bar and choose the
appropriate language.

That could be done. I suggest opening a new bug which concentrates explaining the use case and finding a good solution for it instead of request some specific implementation immediately.

(In reply to comment #12)

They are page names just like everything else, and we don't have all article
names in English in different language Wikipedias.

No, they're not. Is there a way to make this more obvious? :-)

I agree with a "wontfix" here (and I'm re-marking this bug as resolved), but for better reasoning. Localized special page names are good. They're user-facing titles that don't have any need to be in English only. The fact that other parts of the URL are in English are separate bugs, not features.

However, the underlying issue here is that it's annoying to switch between special pages between languages because simple URL manipulation (changing the language code) doesn't work with the special page name being translated. And this is certainly annoying.

There are ways to make the user experience better, but for most users, the answer is most certainly not doing less localization. As someone suggested, you can file a separate request to put other wikis in the sidebar. This has difficulties, of course, as this problem is largely confined to wiki families (as opposed to most MediaWiki installations, which are independent) and in some wiki families, there are a lot of wiki projects (sidebar bloat).

There are other possible solutions to this problem, but any solution has to be weighed against the cost of additional code or consequences to other users. The reality is that using URL manipulation to switch between Special pages is a power-user feature. That's fine, but if it's only going to benefit a very small number of people, they can use power-tools, such as client-side JavaScript. There is already infrastructure in place to make this easier, e.g., https://www.mediawiki.org/wiki/Snippets.

If you get creative, you can surely come up with some other ways to implement this functionality. And that's great. But for core MediaWiki, most users will never hit this use-case, so the additional code and possible consequences (non-translated page titles, etc.) aren't worth it and likely won't ever be.

mr.heat wrote:

(In reply to comment #16)

I agree with a "wontfix" here (and I'm re-marking this bug as resolved), but
for better reasoning. Localized special page names are good. They're
user-facing titles that don't have any need to be in English only.

I'm very sorry but I have to reopen this again. You are right, it's good to have localized titles for the special pages. But the translation should be done in the visible HTML page only and not in the URL.

Here is an other example why translating the URL does not make sense:
http://tr.wikipedia.org/wiki/Özel:ÖnekDizini?uselang=en

• Bug 41811 has been marked as a duplicate of this bug. ***