Last modified: 2014-09-23 19:47:27 UTC
MediaWiki has a very good feature: it gives pages readable URLs that match the page's titles. Unfortunately it doesn't work well with titles that include characters that need to be URL-encoded. In Latin-script wikis this is a relatively small problem, but in wikis which are not Latin, such as Russian, Arabic and many others, this turns nearly every URL into a long string of percent signs and character numbers. Some Wikipedias try to cope with it. In the Malayalam Wikipedia is is common to create redirects in ASCII, but every such redirect must be created manually, which is a bit tedious. There's also the Shortify tool ( http://defn.me/s/ ), which makes the URL short, but unreadable. Maybe the Interlanguage extension can be modified so that typing something like http://mul.wikipedia.org/wiki/Barack_Obama:ar will redirect to http://ar.wikipedia.org/wiki/باراك_أوباما. It wont make the name very short, but it will certainly be better than http://ar.wikipedia.org/wiki/%D8%A8%D8%A7%D8%B1%D8%A7%D9%83_%D8%A3%D9%88%D8%A8%D8%A7%D9%85%D8%A7 for sending by email or instant messaging. ("mul" is the ISO 639 code for "multiple languages". There was no decision to give the future Interlanguage wiki this name; i just made it up. The domain can have any other name. Another proposal is to call it data.wikimedia.org. It's not very important)
To ask the stupid question, why not send http://ar.wikipedia.org/wiki/باراك_أوباما in an email. 99% of modern programs will convert that to the correct percent encoding. This personally seems kind of icky to me. If we did have the ability to resolve interlanguage names like this, and wanted to do something like this, why wouldn't we just make http://ar.wikipedia.org/wiki/<magic name in some other lang> automatically redirect to the correct page?
(In reply to comment #1) > To ask the stupid question, why not send > http://ar.wikipedia.org/wiki/باراك_أوباما in an email. 99% of modern programs > will convert that to the correct percent encoding. It will correct it to the right percent encoding, but it will be very long. Just look at my first comment. And that's a relatively short name; it could be much longer, for example, like http://ar.wikipedia.org/wiki/%D8%A7%D9%84%D8%A3%D9%85%D9%8A%D8%B1%D8%A9_%D9%85%D8%A7%D8%B1%D8%AC%D8%B1%D9%8A%D8%AA_%D9%83%D9%88%D9%86%D8%AA%D9%8A%D8%B3%D8%A9_%D8%B3%D9%86%D9%88%D8%AF%D9%88%D9%86 . It usually goes through, but it's terribly ugly. And in an IM program, like, GMail chat, sending such a link fills the whole screen with percent signs and digits. > This personally seems kind of icky to me. If we did have the ability to resolve > interlanguage names like this, and wanted to do something like this, why > wouldn't we just make http://ar.wikipedia.org/wiki/<magic name in some other > lang> automatically redirect to the correct page? Also possible.
If I understand what you want correctly, you would like all wikis to have links in Latin alphabet, not necessarily short, but still shorter than the current ones. It is possible (srwiki already partly works that way and it could be improved), but I don't think that the Interlanguage Extension could help. For starters, there are no guarantees that Barack Obama on mul would always continue to point to باراك_أوباما on ar. Then, this may work for names, but articles about animals, or scientific terms, or whatever is not similar in most languages will be very dissimilar in English and the target language, thus negating the point of the Latin link.
The goal is not so much to make the URL short as to make it readable, assuming that anyone that is able to read the string "wikipedia.org" is able to read the string "Barack_Obama". A lot of people are able to read both "Barack_Obama" and "باراك_أوباما"; some people are able to read only one of these strings; but i'm quite sure that "%D8%A8%D8%A7%D8%B1%D8%A7%D9%83_%D8%A3%D9%88%D8%A8%D8%A7%D9%85%D8%A7" is equally gibberish to everyone. It doesn't matter what the article is about and what the final name in the target language is. An Interlanguage wiki page is supposed to be a hub that points to the different names of the same thing in different languages, whether it's people, building materials, animals or towns. The name in the target language may change, but then the Interlanguage wiki will probably be updated. What i suggest is that the Interlanguage extension will simply redirect the reader to the article that is currently listed at the same page as the target article in the requested language. If there's no article about this in that language yet, then the extension can offer the reader to create an article in his language.
(In reply to comment #2) > (In reply to comment #1) > > To ask the stupid question, why not send > > http://ar.wikipedia.org/wiki/باراك_أوباما in an email. 99% of modern programs > > will convert that to the correct percent encoding. > > It will correct it to the right percent encoding, but it will be very long. > Just look at my first comment. And that's a relatively short name; it could be > much longer, for example, like > http://ar.wikipedia.org/wiki/%D8%A7%D9%84%D8%A3%D9%85%D9%8A%D8%B1%D8%A9_%D9%85%D8%A7%D8%B1%D8%AC%D8%B1%D9%8A%D8%AA_%D9%83%D9%88%D9%86%D8%AA%D9%8A%D8%B3%D8%A9_%D8%B3%D9%86%D9%88%D8%AF%D9%88%D9%86 > . It usually goes through, but it's terribly ugly. And in an IM program, like, > GMail chat, sending such a link fills the whole screen with percent signs and > digits. I'm not sure this is correct. All of these can redirect to the "ugly encoded" version (depending on your browser) [1]: * http://ar.wikipedia.org/wiki/باراك_أوباما * http://mul.wikipedia.org/wiki/Barack_Obama:ar * http://ar.wikipedia.org/wiki/Barack_Obama So the ugly-ness factor of native-title urls seems irrelevant. The point is the url that you're sharing communication to others, which neither the second or third one is what will be in your browser addressbar. -- Krinkle [1]: For the record, accessing http://ar.wikipedia.org/wiki/باراك_أوباما (not a redirect) in Safari 5 or Firefox 4 does *not* redirect to a url encoded version, neither does MediaWiki link to urlencoded versions from inline links. So I could copy/paste http://ar.wikipedia.org/wiki/باراك_أوباما right from the browser to here.
(In reply to comment #5) > (In reply to comment #2) > * http://ar.wikipedia.org/wiki/باراك_أوباما > * http://mul.wikipedia.org/wiki/Barack_Obama:ar > * http://ar.wikipedia.org/wiki/Barack_Obama > > So the ugly-ness factor of native-title urls seems irrelevant. The point is the > url that you're sharing communication to others, which neither the second or > third one is what will be in your browser addressbar. The link to http://mul.wikipedia.org/wiki/Barack_Obama:ar can appear somewhere on the page. http://ar.wikipedia.org/wiki/%D8%A8%D8%A7%D8%B1%D8%A7%D9%83_%D8%A3%D9%88%D8%A8%D8%A7%D9%85%D8%A7 > [1]: For the record, accessing http://ar.wikipedia.org/wiki/باراك_أوباما (not > a redirect) in Safari 5 or Firefox 4 does *not* redirect to a url encoded > version, neither does MediaWiki link to urlencoded versions from inline links. > So I could copy/paste http://ar.wikipedia.org/wiki/باراك_أوباما right from the > browser to here. Firefox 4 on XP shows it nicely in the address bar, but URD-encodes it when it's copied and pasted...
Doesn't shorturl extension already fix this issue?
