-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Körner:
I'd like to have this possibility in my tools to select the source wikipedia. If s/o uses it for translation, that's his thing ;) So I'd too vote for this feature.
This is one good reason *not* to implement this feature -- we might intend for it to be used for interface language selection, but then someone starts using it for something completely different, like selecting Wikipedia language to operate on. This would achieve nothing except confusing users, and render the feature useless.
I'm inclined not to implement this, because I don't see why interface language should get special treatment. For example, most tools have a way to specify what project to operate on; should we support http://de.enwiki.toolserver.org/~jsmith/mytool.fcgi to specify that results should come from en.wikipedia.org and the interface should be in German?
The parallel to "en.wikipedia.org" / "de.wikipedia.org" is not a convincing argument, because dewiki is not just a translated version of enwiki, it's a completely separate site.
Furthermore, this URL scheme breaks the hierarchical nature of a URL. Normal URLs form a tree-like structure. Given the following URLs:
http://en.wikipedia.org/wiki/Main_Page http://toolserver.org/~jsmith/tool1.fcgi http://toolserver.org/~jsmith/tool2.fcgi http://toolserver.org/~jdoe/tool1.fcgi
a tree could be drawn like this:
http:// / \ / \ toolserver.org en.wikipedia.org / | | ~jsmith ~jdoe wiki / | \ | tool1.fcgi tool2.fcgi tool1.fcgi Main_Page
But if the following URLs both refer to the same resource:
http://en.toolserver.org/~jsmith/tool1.fcgi http://de.toolserver.org/~jsmith/tool1.fcgi
then you no longer represent the namespace as a tree; instead it's become a graph.
Finally, I don't see any actual advantage to this proposal; it doesn't seem to do anything that a query parameter can't do.
- river.