Hey, guys.
I've had an epiphany today about internationalization of the Toolserver tools.
You see, right now we have to create our own ways to provide more languages: * http://toolserver.org/~holek/cite-gen/index.php?scriptlang=gsw * http://toolserver.org/~soxred93/pcount/index.php?uselang=ckb etc. etc.
What I propose is language subdomains, much like Wikimedia projects have. All language subdomains would refer to the same directories, so we could just do Apache's ServerAlias equivalent on ZWS.
This would make possible for developers to read the language user wants directly from the subdomain, instead of relying on seperate tool implementation of translations.
And by that, I mean just using different parameters to describe user's desired language, not how to achieve this. So, for example, above links would look like this: * http://gsw.toolserver.org/~holek/cite-gen/index.php * http://ckb.toolserver.org/~soxred93/pcount/index.php
A tool reades subdomain's code and uses a correct language, much like it would do with an additional parameter... ... but this parameter is now gone and is not cluttering the query string. :)
-- Mike Połtyn
-- P.S. this message is a duplicate, so I apologize if the first one arrives as well. I've had some problems with my mailing list account
On 12/29/2010 03:11 PM, Mike Połtyn wrote:
I've had an epiphany today about internationalization of the Toolserver tools.
You see, right now we have to create our own ways to provide more languages:
- http://toolserver.org/~holek/cite-gen/index.php?scriptlang=gsw
- http://toolserver.org/~soxred93/pcount/index.php?uselang=ckb
etc. etc.
What I propose is language subdomains, much like Wikimedia projects have. All language subdomains would refer to the same directories, so we could just do Apache's ServerAlias equivalent on ZWS.
This would make possible for developers to read the language user wants directly from the subdomain, instead of relying on seperate tool implementation of translations.
And by that, I mean just using different parameters to describe user's desired language, not how to achieve this. So, for example, above links would look like this:
Hmm, that could indeed work. Of course, 5 minutes after it's enabled, someone will file a bug report saying that it doesn't work, because when they go to gsw.toolserver.org, all (99.9%) of the content is still in English. :) But I guess that's not really a serious obstacle, just a minor but inevitable side effect.
Hello,
the developers of the WWW were clever enough to create a http-header-field for that (Accept-Language) ;-). It's easy to just read that field and use it for i18n, so there is in theory no need for a parameter at all (it is nice to have a parameter TOO, for people with wrong accpet-header or for links).
Sincerly, DaB.
On 29 December 2010 16:19, DaB. WP@daniel.baur4.info wrote:
Hello,
the developers of the WWW were clever enough to create a http-header-field for that (Accept-Language) ;-). It's easy to just read that field and use it for i18n, so there is in theory no need for a parameter at all (it is nice to have a parameter TOO, for people with wrong accpet-header or for links).
AFAIK most of us do so (including me), but we also don't want people to be stuck with a language of our automatic choice. So, the parameter in query string is just being replaced by a subdomain name
On Wed, Dec 29, 2010 at 6:12 PM, Daniel Schwen lists@schwen.de wrote:
AFAIK most of us do so (including me), but we also don't want people to be stuck with a language of our automatic choice. So, the parameter
It is not automatic, you are not stuck, you can configure it in your browser or operating system.
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
And here a problem arises. Not all operating systems and browsers are translated in every language. For example, there's still no Belarusian Windows and Internet Explorer. There's no Belarusian Chrome furthermore.
So it's a bit more complicated from the second sight.
Paul Selitskas wrote:
And here a problem arises. Not all operating systems and browsers are translated in every language. For example, there's still no Belarusian Windows and Internet Explorer. There's no Belarusian Chrome furthermore.
So it's a bit more complicated from the second sight.
You don't need it to be translated. You need to configure it in order to give out the proper accept-language. That's different than the language you have set your OS or browser (although they are likely to be the same).
On Wed, Dec 29, 2010 at 5:19 PM, DaB. WP@daniel.baur4.info wrote:
Hello,
the developers of the WWW were clever enough to create a http-header-field for that (Accept-Language) ;-). It's easy to just read that field and use it for i18n, so there is in theory no need for a parameter at all (it is nice to have a parameter TOO, for people with wrong accpet-header or for links).
Sincerly, DaB.
-- Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Yes, and parameters MUST override accept-language as it makes no sense otherwise.
On Wed, Dec 29, 2010 at 4:19 PM, DaB. WP@daniel.baur4.info wrote:
Hello,
the developers of the WWW were clever enough to create a http-header-field for that (Accept-Language) ;-).
The problem is that this header field is either impossible or difficult to change, and even then only browser-wide, not site-wide. Also, what about those whose OS/browser language is set to English, because the rest of his OS/browser is not properly or not at all translated/available in the language the user wants to see the site? I'm thinking especially of the "minor" languages like Bavarian here... there's no Bavarian MS Windows, Linux/*nix locale... so how should a Bavarian tell the browser that he'd like to see the tool in Bavarian instead of "normal" German? What about real languages we have a Wikipedia and active translators for, but no recognition/implementation by anyone except Wikimedia? They'd all be forced to use English versions.
Marco
At Wednesday 29 December 2010 18:39:07 DaB. wrote:
The problem is that this header field is either impossible or difficult to change, and even then only browser-wide, not site-wide.
4 clicks in FF, 3 clicks in IE, 5 clicks in chromium – very hard indeed. And what's the advantage to look at 1 tool in german and 1 tool in french? If I speak french and english that will not change depending if I look at google or at heise. And yes, there is no pre-definied locale for bavaria-dialect – what a pitty, because we have SO many tools that are localized in that language and now noone can see it! (I would be happy if the tools would be avaiable in the 5 biggest languages at all). And if that REALLY would be a problem, there is still the parameter left.
Sincerly, DaB.
Hi,
Am 29.12.2010, 18:50 Uhr, schrieb DaB. WP@daniel.baur4.info:
At Wednesday 29 December 2010 18:39:07 DaB. wrote:
The problem is that this header field is either impossible or difficult to change, and even then only browser-wide, not site-wide.
4 clicks in FF, 3 clicks in IE, 5 clicks in chromium – very hard indeed. And what's the advantage to look at 1 tool in german and 1 tool in french?
the problem is, that one wants to give consistent links to others. When you're not able to give a link, which points to the same page (in the same language), thats not very user friendly I think. Of course the header field should be used when toolserver.org or www.toolserver.org is the host and may redirect to en.toolserver.org or de.toolserver.org regarding to the language preferences.
Another point: I'm sure 99% of internet users don't know about this browser setting and of the rest a high percentage will not be able to change it. You know it, I know it, but my mother don't know.
Using this field gives you a a good standard language, but language switching is necessary too.
Greets, Christian Thiele / apper
Hello, At Wednesday 29 December 2010 22:10:53 DaB. wrote:
the problem is, that one wants to give consistent links to others. When you're not able to give a link, which points to the same page (in the same language), thats not very user friendly I think. Of course the header field should be used when toolserver.org or www.toolserver.org is the host and may redirect to en.toolserver.org or de.toolserver.org regarding to the language preferences.
yes, that's the problem, but the way arround. If I give a link like http://en.toolserver.org/~auser/atool.php to another user the GUI will be in english – no matter if the user speaks english, his accept-header is english or anything. Also the way to specify the language in a third-level-domain is VERY uncommon (wikipedia does it and a few hardware-sellers like IBM or dell) – the users are accustomed to change the first-level-domain (google.de for german google, google.fr for french google, google.it for italian etc. pp.).
Another point: I'm sure 99% of internet users don't know about this browser setting and of the rest a high percentage will not be able to change it. You know it, I know it, but my mother don't know.
sure, and what is the first thing you do after you installed a browser for a non-interrested user like your mother? You install a language pack, so the browser's GUI is for example in german – and that also (at least in firefox) sets the accept-header correct.
Using this field gives you a a good standard language, but language switching is necessary too.
You still can use a parameter for that, if you really like.
Sincerly, DaB.
DaB. (2010-12-29 22:21):
Hello, At Wednesday 29 December 2010 22:10:53 DaB. wrote:
the problem is, that one wants to give consistent links to others. When you're not able to give a link, which points to the same page (in the same language), thats not very user friendly I think. Of course the header field should be used when toolserver.org or www.toolserver.org is the host and may redirect to en.toolserver.org or de.toolserver.org regarding to the language preferences.
yes, that's the problem, but the way arround. If I give a link like http://en.toolserver.org/~auser/atool.php to another user the GUI will be in english – no matter if the user speaks english, his accept-header is english or anything. Also the way to specify the language in a third-level-domain is VERY uncommon (wikipedia does it and a few hardware-sellers like IBM or dell) – the users are accustomed to change the first-level-domain (google.de for german google, google.fr for french google, google.it for italian etc. pp.).
It's also not standard for Wikipedia. If I go to de.wikipedia.org I see interface in language I've chosen in preferences (which happens to be Polish). The difference is not the interface (which to my understanding we are talking about), the difference is the active database. You would have to add the ability to change the database and the interface language anyway.
Anyway how would it be possible to make toolserver users to use one common method for i10n? There is no suggested framework there aren't even any suggested templates for a page (by which I mean a common layout).
Regards, Nux.
That's extremely the wrong way of discussion. The initial question was, as I suppos, if there could be created rewrite rule to change thrid domain name with something like '?uselang=$1'. Such a radical "improvement" is unnecessary.
On Thu, Dec 30, 2010 at 12:16 AM, Maciej Jaros egil@wp.pl wrote:
DaB. (2010-12-29 22:21):
Hello, At Wednesday 29 December 2010 22:10:53 DaB. wrote:
the problem is, that one wants to give consistent links to others. When you're not able to give a link, which points to the same page (in the same language), thats not very user friendly I think. Of course the header field should be used when toolserver.org or www.toolserver.org is the host and may redirect to en.toolserver.org or de.toolserver.org regarding to the language preferences.
yes, that's the problem, but the way arround. If I give a link like http://en.toolserver.org/~auser/atool.php to another user the GUI will be in english – no matter if the user speaks english, his accept-header is english or anything. Also the way to specify the language in a third-level-domain is VERY uncommon (wikipedia does it and a few hardware-sellers like IBM or dell) – the users are accustomed to change the first-level-domain (google.de for german google, google.fr for french google, google.it for italian etc. pp.).
It's also not standard for Wikipedia. If I go to de.wikipedia.org I see interface in language I've chosen in preferences (which happens to be Polish). The difference is not the interface (which to my understanding we are talking about), the difference is the active database. You would have to add the ability to change the database and the interface language anyway.
Anyway how would it be possible to make toolserver users to use one common method for i10n? There is no suggested framework there aren't even any suggested templates for a page (by which I mean a common layout).
Regards, Nux.
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Paul Selitskas (2010-12-29 23:25):
That's extremely the wrong way of discussion. The initial question was, as I suppos, if there could be created rewrite rule to change thrid domain name with something like '?uselang=$1'. Such a radical "improvement" is unnecessary.
It doesn't matter how it will be used (I mean the subdomain) pl.wikipedia.org means I'm going to Polish Wikipedia articles not that I'm using Polish interface.
On Thu, Dec 30, 2010 at 12:16 AM, Maciej Jarosegil@wp.pl wrote:
DaB. (2010-12-29 22:21):
Hello, At Wednesday 29 December 2010 22:10:53 DaB. wrote:
the problem is, that one wants to give consistent links to others. When you're not able to give a link, which points to the same page (in the same language), thats not very user friendly I think. Of course the header field should be used when toolserver.org or www.toolserver.org is the host and may redirect to en.toolserver.org or de.toolserver.org regarding to the language preferences.
yes, that's the problem, but the way arround. If I give a link like http://en.toolserver.org/~auser/atool.php to another user the GUI will be in english – no matter if the user speaks english, his accept-header is english or anything. Also the way to specify the language in a third-level-domain is VERY uncommon (wikipedia does it and a few hardware-sellers like IBM or dell) – the users are accustomed to change the first-level-domain (google.de for german google, google.fr for french google, google.it for italian etc. pp.).
It's also not standard for Wikipedia. If I go to de.wikipedia.org I see interface in language I've chosen in preferences (which happens to be Polish). The difference is not the interface (which to my understanding we are talking about), the difference is the active database. You would have to add the ability to change the database and the interface language anyway.
Anyway how would it be possible to make toolserver users to use one common method for i10n? There is no suggested framework there aren't even any suggested templates for a page (by which I mean a common layout).
Regards, Nux.
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Then there no such discussion should take place. Toolserver is a host of more or less multi-wikipedia tools, differentiating domain names for used databases is awkward and weird.
On Thu, Dec 30, 2010 at 3:19 AM, Maciej Jaros egil@wp.pl wrote:
Paul Selitskas (2010-12-29 23:25):
That's extremely the wrong way of discussion. The initial question was, as I suppos, if there could be created rewrite rule to change thrid domain name with something like '?uselang=$1'. Such a radical "improvement" is unnecessary.
It doesn't matter how it will be used (I mean the subdomain) pl.wikipedia.org means I'm going to Polish Wikipedia articles not that I'm using Polish interface.
On Thu, Dec 30, 2010 at 12:16 AM, Maciej Jarosegil@wp.pl wrote:
DaB. (2010-12-29 22:21):
Hello, At Wednesday 29 December 2010 22:10:53 DaB. wrote:
the problem is, that one wants to give consistent links to others. When you're not able to give a link, which points to the same page (in the same language), thats not very user friendly I think. Of course the header field should be used when toolserver.org or www.toolserver.org is the host and may redirect to en.toolserver.org or de.toolserver.org regarding to the language preferences.
yes, that's the problem, but the way arround. If I give a link like http://en.toolserver.org/~auser/atool.php to another user the GUI will be in english – no matter if the user speaks english, his accept-header is english or anything. Also the way to specify the language in a third-level-domain is VERY uncommon (wikipedia does it and a few hardware-sellers like IBM or dell) – the users are accustomed to change the first-level-domain (google.de for german google, google.fr for french google, google.it for italian etc. pp.).
It's also not standard for Wikipedia. If I go to de.wikipedia.org I see interface in language I've chosen in preferences (which happens to be Polish). The difference is not the interface (which to my understanding we are talking about), the difference is the active database. You would have to add the ability to change the database and the interface language anyway.
Anyway how would it be possible to make toolserver users to use one common method for i10n? There is no suggested framework there aren't even any suggested templates for a page (by which I mean a common layout).
Regards, Nux.
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
On Wed, Dec 29, 2010 at 6:50 PM, DaB. WP@daniel.baur4.info wrote:
At Wednesday 29 December 2010 18:39:07 DaB. wrote:
The problem is that this header field is either impossible or difficult to change, and even then only browser-wide, not site-wide.
4 clicks in FF, 3 clicks in IE, 5 clicks in chromium – very hard indeed. And what's the advantage to look at 1 tool in german and 1 tool in french? If I speak french and english that will not change depending if I look at google or at heise.
*We* know how to change it, yes. The end-user does not necessarily know, because you normally don't really need it (even if the field itself is a nice thing to have!). BTW, what about closed platforms like iOS, Android and Windows Mobile/Phone 7? The subdomain makes sure that the same URL will give the same result on every platform when they click on the same link in Wikipedia/Wikisource/whatever. But that gives me another idea: Why not store the display language in a cookie, just like it's done with CentralAuth? This way, you can set it right inside MediaWiki and don't have to care about changing your browser/OS setting at all.
Marco
Hi,
Op 29-12-2010 16:19, DaB. schreef:
Hello,
the developers of the WWW were clever enough to create a http-header-field for that (Accept-Language) ;-).
A while ago I collected some accept-language data at Commons, you can see the result at http://commons.wikimedia.org/wiki/Commons:Template_i18n/Interface_language_s... . Gives an impression of what languages you'll encounter in the wild.
Op 29-12-2010 17:14, Paul Selitskas schreef:
And here a problem arises. Not all operating systems and browsers are translated in every language. For example, there's still no Belarusian Windows and Internet Explorer. There's no Belarusian Chrome furthermore.
I see 207.000 Belarusian hits so someone managed to send that language code ;-)
Maarten
On Wed, Dec 29, 2010 at 10:48 PM, Maarten Dammers maarten@mdammers.nl wrote:
Op 29-12-2010 17:14, Paul Selitskas schreef:
And here a problem arises. Not all operating systems and browsers are translated in every language. For example, there's still no Belarusian Windows and Internet Explorer. There's no Belarusian Chrome furthermore.
I see 207.000 Belarusian hits so someone managed to send that language code ;-)
Maarten
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Yeah, I'm some kind of liar. :) Although some languages still lack support by browsers (and here I mean not the interface language, but languages in Content settings).
BTW, thanks for stats. A big stimulus to continue i18n of Wikimedia for Belarusians.
Hi
So with a german OS/Browser I wouldn't be able to see statistics about the english Wikipedia or english OSM-Maps?
The Accept-Header is useful for translations, but there's still a need for users to actively select another Wikipedia.
Peter
Am 29.12.2010 16:19, schrieb DaB.:
Hello,
the developers of the WWW were clever enough to create a http-header-field for that (Accept-Language) ;-). It's easy to just read that field and use it for i18n, so there is in theory no need for a parameter at all (it is nice to have a parameter TOO, for people with wrong accpet-header or for links).
Sincerly, DaB.
Hello, Am Mittwoch 29 Dezember 2010, 22:17:46 schrieb Peter Körner:
The Accept-Header is useful for translations, but there's still a need for users to actively select another Wikipedia.
that's another topic, which has nothing to do with the discussion :-). The discussion is only about l10n and how to do it, not about which wiki a tool should use for it's work.
Sincerly, DaB.
Am 29.12.2010 22:28, schrieb DaB.:
Hello, Am Mittwoch 29 Dezember 2010, 22:17:46 schrieb Peter Körner:
The Accept-Header is useful for translations, but there's still a need for users to actively select another Wikipedia.
that's another topic, which has nothing to do with the discussion :-). The discussion is only about l10n and how to do it, not about which wiki a tool should use for it's work.
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.
Peter
-----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.
I'm just going to throw this out there, because it's been bugging me today.
It is i18n. Not i10n. There is no such thing as i10n. There is i18n, for internalization, and l10n, for localization.
End rant.
-X!
toolserver-l@lists.wikimedia.org