Hello!
Does anybody knows why the link http://en.wikipedia.org/wiki/Special:ListUsers/autoreviewer makes the target page to have the box on the right filled with "Autoreviewers" and shows only the users in that group, while using a translated name at pt.wikipedia, like http://pt.wikipedia.org/wiki/Especial:Lista_de_utilizadores/Rob%C3%B4shttp://pt.wikipedia.org/wiki/Especial:Lista_de_utilizadores/Rob%C3%B4s doesn't do the same thing? (in this example, we get a list of all users, starting from "Robôs")
Is it possible to use a translated name in the link for this kind of special page? (lists of users in a group)
Helder
2009/8/30 Helder Geovane Gomes de Lima heldergeovane@gmail.com:
Hello!
Does anybody knows why the link http://en.wikipedia.org/wiki/Special:ListUsers/autoreviewer makes the target page to have the box on the right filled with "Autoreviewers" and shows only the users in that group, while using a translated name at pt.wikipedia, like http://pt.wikipedia.org/wiki/Especial:Lista_de_utilizadores/Rob%C3%B4shttp://pt.wikipedia.org/wiki/Especial:Lista_de_utilizadores/Rob%C3%B4s doesn't do the same thing? (in this example, we get a list of all users, starting from "Robôs")
Is it possible to use a translated name in the link for this kind of special page? (lists of users in a group)
It seems you have to use the English name, which is presumably the name used in the code. It is probably possible to make it so aliases work - I suggest leaving a feature request on https://bugzilla.wikimedia.org/ .
On Sun, Aug 30, 2009 at 1:58 PM, Helder Geovane Gomes de Limaheldergeovane@gmail.com wrote:
Does anybody knows why the link http://en.wikipedia.org/wiki/Special:ListUsers/autoreviewer makes the target page to have the box on the right filled with "Autoreviewers" and shows only the users in that group, while using a translated name at pt.wikipedia, like http://pt.wikipedia.org/wiki/Especial:Lista_de_utilizadores/Rob%C3%B4shttp://pt.wikipedia.org/wiki/Especial:Lista_de_utilizadores/Rob%C3%B4s doesn't do the same thing? (in this example, we get a list of all users, starting from "Robôs")
Is it possible to use a translated name in the link for this kind of special page? (lists of users in a group)
The parameter in the URL currently must be an exact match for the name of the group. Group names are normally short, lowercase, ASCII, alphabetic English names that are consistent across wikis. You can think of them like numbers, as if the URL were /w/index.php?title=Special:ListUsers&groupid=14 or something; they're meant to be opaque identifiers for use by system administrators, not user-visible strings.
Do we expose group names anywhere other than URLs and message names? Message names aren't really an issue, since those are entirely English anyway. I think it's not worth the effort of localizing if they only appear in URLs. We already have some English in the http://pt.wikipedia.org/wiki/ part of the URL anyway, and English in all the GET parameter names, and so on.
Aryeh Gregor hett schreven:
The parameter in the URL currently must be an exact match for the name of the group. Group names are normally short, lowercase, ASCII, alphabetic English names that are consistent across wikis. You can think of them like numbers, as if the URL were /w/index.php?title=Special:ListUsers&groupid=14 or something; they're meant to be opaque identifiers for use by system administrators, not user-visible strings.
Do we expose group names anywhere other than URLs and message names? Message names aren't really an issue, since those are entirely English anyway. I think it's not worth the effort of localizing if they only appear in URLs. We already have some English in the http://pt.wikipedia.org/wiki/ part of the URL anyway, and English in all the GET parameter names, and so on.
But that would be inconsistent with us localising special page names which too appear in URLs only. So in my opinion they should be localized.
Marcus Buck User:Slomox
"Marcus Buck" wiki@marcusbuck.org wrote in message news:4A9AEE20.7000005@marcusbuck.org...
But that would be inconsistent with us localising special page names which too appear in URLs only. So in my opinion they should be localized.
Not true: special page names are localised in the JS variables (wgPageName, for instance), and in the class applied to <body>; and of course in links everywhere across the site. The two aren't at all comparable. The comparison of user or page ids is much more accurate.
--HM
On 8/30/09 8:08 PM, Happy-melon wrote:
"Marcus Buck"wiki@marcusbuck.org wrote in message news:4A9AEE20.7000005@marcusbuck.org...
But that would be inconsistent with us localising special page names which too appear in URLs only. So in my opinion they should be localized.
Not true: special page names are localised in the JS variables (wgPageName, for instance), and in the class applied to<body>; and of course in links everywhere across the site. The two aren't at all comparable. The comparison of user or page ids is much more accurate.
They're *certainly* comparable -- namespaces and special page names have canonical names (ASCII-friendly English), per-language localizations and aliases, and locally-configured aliases and overrides (via config file).
We've always exposed the content-language localized variants of the namespaces to URLs, and started doing this for special page names as well in more recent years.
This is a trade-off which is usually friendlier to most users (they can read the text in URLs in their own language) while moderately annoying to some power users use cases (copy-pasting a path from one site to another may not work, it may be harder to identify pages on a site whose language you do not speak but are performing maintenance editing or debugging on).
User groups have canonical names (usually ASCII-friendly English), and two localized forms (for individual members and for the group as a whole), which are set via the localization system or locally configured via MediaWiki: messages.
It would not be terribly difficult to use content-language localized forms on the special page URLs where we most prominently use group names, or at least to accept them if provided; the primary problem area I see is in providing backwards-compatibility when the localizations change.
With namespace names and special page names maintained in the localization files or via site configuration, we take great care to keep old names as aliases when they're changed in order to keep old links working if possible.
There's currently no similar alias infrastructure for localized group names, which are provided and formatted for use in UI output and not (yet?) intended for URL input.
-- brion
On Sun, Aug 30, 2009 at 5:24 PM, Marcus Buckwiki@marcusbuck.org wrote:
But that would be inconsistent with us localising special page names which too appear in URLs only.
Special page names also appear in the title of the page when you view it, which is a very visible location. And on Special:AllPages, and probably other places. It's not the same at all.
On Sun, Aug 30, 2009 at 7:27 PM, Brion Vibberbrion@wikimedia.org wrote:
They're *certainly* comparable -- namespaces and special page names have canonical names (ASCII-friendly English), per-language localizations and aliases, and locally-configured aliases and overrides (via config file).
Well, yes, but we could add those for anything. We *could* add per-language localizations for GET parameters too, if we liked; it wouldn't be too hard, just add some magic to WebRequest and start converting HTML outputters. But that would be unreasonable. I agree that more localization is good, but where's the dividing line? The usergroup name in this case is only a GET parameter value dressed up as a subpage. Should we also localize log subpages? How many other special pages behave like this?
This is a trade-off which is usually friendlier to most users (they can read the text in URLs in their own language) while moderately annoying to some power users use cases (copy-pasting a path from one site to another may not work, it may be harder to identify pages on a site whose language you do not speak but are performing maintenance editing or debugging on).
Tangentially, is there any actual reason we couldn't allow any language's alias (e.g., for special page names or namespaces) to work in any other language? We'd have to make sure we have a moderately sane way of resolving conflicts, but those should be extremely uncommon.
It would not be terribly difficult to use content-language localized forms on the special page URLs where we most prominently use group names, or at least to accept them if provided; the primary problem area I see is in providing backwards-compatibility when the localizations change.
For Special:ListUsers, a possibly more serious problem is that the localized group name might conflict with a username, since the parameter is overloaded. We avoid conflicts right now only because canonical group names are conventionally all lowercase, and usernames can't start with a lowercase letter. (At least not a lowercase ASCII letter?)
Aryeh Gregor wrote:
Tangentially, is there any actual reason we couldn't allow any language's alias (e.g., for special page names or namespaces) to work in any other language? We'd have to make sure we have a moderately sane way of resolving conflicts, but those should be extremely uncommon.
You get a request for page Foo:Bar. It could be a page name, or Foo could mean Special in Bantu. How do you check (efficiently) over 300 languages? I'd prefer an option (stored as a global preference) to use canonical names instead of localised ones. It doesn't need to redirect from localised to canonical, simply keep the url which was inputted.
It's uncomfortable browsing to xy.wikipedia.org/wiki/Special:something, then moving to check it on yx.wikpedia, and having to go back to retype the pagename because "Spécialis:somethingelese doesn't exist". Having canonical pagenames also used to be helpful when browsing a wiki on a foreign language to determine which link lead to eg. the contributions of a user, by hovering the different options (now you will need to change to ?uselang=). That's a feature that wouldn't be used by most users, but people doing crosswiki work, like stewards or members of SWMT, would surely find it useful.
On Sun, Aug 30, 2009 at 8:37 PM, PlatonidesPlatonides@gmail.com wrote:
You get a request for page Foo:Bar. It could be a page name, or Foo could mean Special in Bantu. How do you check (efficiently) over 300 languages?
Ouch. Okay, that's out for namespaces. It should work fine for special page names, though, right? Although I guess that's semi-pointless if the "Special:" part doesn't work.
Clearly it was a bad idea to use a character for namespace separator that's allowed in page names. Crazy idea, but maybe we could still change . . . would it cause conflicts to use ">", say? Then we could display the namespace in a breadcrumb-y fashion, with spaces on either side. Obviously we'd accept ":" forever as well, for compatibility. I'd think it would be pretty easy to get most stuff working with a new namespace separator, just some hackery with Title::secureAndSplit() should do it.
I'd prefer an option (stored as a global preference) to use canonical names instead of localised ones. It doesn't need to redirect from localised to canonical, simply keep the url which was inputted.
It's uncomfortable browsing to xy.wikipedia.org/wiki/Special:something, then moving to check it on yx.wikpedia, and having to go back to retype the pagename because "Spécialis:somethingelese doesn't exist". Having canonical pagenames also used to be helpful when browsing a wiki on a foreign language to determine which link lead to eg. the contributions of a user, by hovering the different options (now you will need to change to ?uselang=).
This should work fine with a global language preference, shouldn't it?
Aryeh Gregor wrote:
On Sun, Aug 30, 2009 at 8:37 PM, PlatonidesPlatonides@gmail.com wrote:
You get a request for page Foo:Bar. It could be a page name, or Foo could mean Special in Bantu. How do you check (efficiently) over 300 languages?
Ouch. Okay, that's out for namespaces. It should work fine for special page names, though, right? Although I guess that's semi-pointless if the "Special:" part doesn't work.
Special page names are better in the sense that you know what it is offhand, but i'm not sure if such search is still acceptable.
Clearly it was a bad idea to use a character for namespace separator that's allowed in page names. Crazy idea, but maybe we could still change . . . would it cause conflicts to use ">", say?
I don't think it'd get too much support.
Then we could display the namespace in a breadcrumb-y fashion, with spaces on either side. Obviously we'd accept ":" forever as well, for compatibility. I'd think it would be pretty easy to get most stuff working with a new namespace separator, just some hackery with Title::secureAndSplit() should do it.
You would need to deal with the parser, for linking to non-ns0 namespaces. I'd prefer not to add a new complexity there.
I'd prefer an option (stored as a global preference) to use canonical names instead of localised ones. It doesn't need to redirect from localised to canonical, simply keep the url which was inputted.
It's uncomfortable browsing to xy.wikipedia.org/wiki/Special:something, then moving to check it on yx.wikpedia, and having to go back to retype the pagename because "Spécialis:somethingelese doesn't exist". Having canonical pagenames also used to be helpful when browsing a wiki on a foreign language to determine which link lead to eg. the contributions of a user, by hovering the different options (now you will need to change to ?uselang=).
This should work fine with a global language preference, shouldn't it?
Only for the later usecase. And it's more intrusive. You may want some wikis to be kept on the original language and understand enough for the other just with url tips.
On Mon, Aug 31, 2009 at 5:04 AM, PlatonidesPlatonides@gmail.com wrote:
Special page names are better in the sense that you know what it is offhand, but i'm not sure if such search is still acceptable.
Why not? I can't think of any problems.
I don't think it'd get too much support.
Maybe, but substantive objections would be useful.
You would need to deal with the parser, for linking to non-ns0 namespaces. I'd prefer not to add a new complexity there.
It has nothing to do with the parser. When the parser finds a link, it just passes it off to a Title method. As far as I can think (without having actually tried it), it would be a fairly small change.
It's uncomfortable browsing to xy.wikipedia.org/wiki/Special:something, then moving to check it on yx.wikpedia, and having to go back to retype the pagename because "Spécialis:somethingelese doesn't exist". Having canonical pagenames also used to be helpful when browsing a wiki on a foreign language to determine which link lead to eg. the contributions of a user, by hovering the different options (now you will need to change to ?uselang=).
This should work fine with a global language preference, shouldn't it?
Only for the later usecase.
Why doesn't it work for the first use case?
Aryeh Gregor wrote:
On Mon, Aug 31, 2009 at 5:04 AM, Platonides wrote:
Special page names are better in the sense that you know what it is offhand, but i'm not sure if such search is still acceptable.
Why not? I can't think of any problems.
They still are a lot of languages?
I don't think it'd get too much support.
Maybe, but substantive objections would be useful.
You would need to deal with the parser, for linking to non-ns0 namespaces. I'd prefer not to add a new complexity there.
It has nothing to do with the parser. When the parser finds a link, it just passes it off to a Title method. As far as I can think (without having actually tried it), it would be a fairly small change.
There might be ugly cases of <nowiki> or other tag extensions inside [[ getting a different behavior.
This should work fine with a global language preference, shouldn't it?
Only for the later usecase.
Why doesn't it work for the first use case?
The special page names are shown in the content language, not in the user language.
On Mon, Aug 31, 2009 at 11:10 AM, PlatonidesPlatonides@gmail.com wrote:
They still are a lot of languages?
Why is that a problem, exactly?
There might be ugly cases of <nowiki> or other tag extensions inside [[ getting a different behavior.
<nowiki> is handled before links are, so it will behave the same as now.
Actually, didn't someone recently commit a change allowing ">" in titles that Brion reverted?
The special page names are shown in the content language, not in the user language.
Hmm, true. There would be no reason for that if the special page name (with namespace) actually worked on all languages.
Platonides wrote:
Aryeh Gregor wrote:
Tangentially, is there any actual reason we couldn't allow any language's alias (e.g., for special page names or namespaces) to work in any other language? We'd have to make sure we have a moderately sane way of resolving conflicts, but those should be extremely uncommon.
You get a request for page Foo:Bar. It could be a page name, or Foo could mean Special in Bantu. How do you check (efficiently) over 300 languages?
With array_key_exists(), surely? It's (AFAIK) a (nearly) constant-time hash lookup.
Of course, you don't want to have to load 300 Messages*.php files just to populate that array in the first place, but that just means that we'd have to consolidate the namespace aliases into a single file if we wanted to do this, rather than scattering them across hundreds of files like we do now.
I've actually long wanted something like this for Commons. At the very least, It Would Be Nice If all the localized aliases of the File/Image namespace were added to $wgNamespaceAliases for Commons.
On 8/31/09 1:12 PM, Ilmari Karonen wrote:
Platonides wrote:
You get a request for page Foo:Bar. It could be a page name, or Foo could mean Special in Bantu. How do you check (efficiently) over 300 languages?
With array_key_exists(), surely? It's (AFAIK) a (nearly) constant-time hash lookup.
Of course, you don't want to have to load 300 Messages*.php files just to populate that array in the first place, but that just means that we'd have to consolidate the namespace aliases into a single file if we wanted to do this, rather than scattering them across hundreds of files like we do now.
I've actually long wanted something like this for Commons. At the very least, It Would Be Nice If all the localized aliases of the File/Image namespace were added to $wgNamespaceAliases for Commons.
While a good, performant implementation might be a little hairy, and the idea of name conflicts makes me break out in cold sweats, it *would* be nice if that worked, yes. :D
-- brion
wikitech-l@lists.wikimedia.org