New user accounts on Wikimedia Commons automatically get a greeting from [[User:Wikimedia Commons Welcome]]. However, this greeting is in English and not all users speak English. At the top of the message there is a list of links to translations in other languages, but I think there is a better way.
Since most new user accounts on Commons (about two thirds) are created by SUL, and arrive through a link that specifies the uselang= parameter, wouldn't it be very easy to set the user preference for user interface language from the uselang parameter when the account is created by SUL?
The greeting template (and other templates, such as deletion requests) could then access the user's interface language setting through a {{USELANG}} magic word, and present the corresponding translation.
This way, new Swedish speaking users (who typically arrive from the Swedish Wikipedia, one that doesn't allow local uploads) could be guided to the Swedish language village pump and find a community there.
On Saturday 06 December 2008 17:49:04 Lars Aronsson wrote:
New user accounts on Wikimedia Commons automatically get a greeting from [[User:Wikimedia Commons Welcome]]. However, this greeting is in English and not all users speak English. At the top of the message there is a list of links to translations in other languages, but I think there is a better way.
Since most new user accounts on Commons (about two thirds) are created by SUL, and arrive through a link that specifies the uselang= parameter, wouldn't it be very easy to set the user preference for user interface language from the uselang parameter when the account is created by SUL?
The greeting template (and other templates, such as deletion requests) could then access the user's interface language setting through a {{USELANG}} magic word, and present the corresponding translation.
This way, new Swedish speaking users (who typically arrive from the Swedish Wikipedia, one that doesn't allow local uploads) could be guided to the Swedish language village pump and find a community there.
This perhaps isn't directly related to your initial query, but I was thinking along similar lines on how to make MediaWiki more internationalized.
MediaWiki is, of course, an excellently internationalized piece of software already. It works excellently with a lot of languages - but what it lacks is the ability to work with more languages at the same time. This is very important on Commons or Meta.
The first step would be to make uselang sticky (or to create a new parameter, for example 'forcelang'), as is the case now with 'variant'. Right now, when someone comes to http://commons.wikimedia.org/?uselang=sr everything is displayed in Serbian, properly, but when he/she clicks on "Log in / create account", the interface goes back to English and someone who doesn't know English can't create the account. But if you go to f.e. http://zh.wikipedia.org/w/index.php?title=%E9%A6%96%E9%A1%B5&variant=zh-... you will see that variant parameter is "inherited" by the links on the page, and whenever you go on the wiki you will remain in the same variant. If uselang would work in the same way, that's one MAJOR improvement already. Since a system for doing this with 'variant' already works, I hope this wouldn't be too hard to do.
And then, what you say. But there exists one caveat - caching. More on this in some future email :)
---------- Forwarded message ---------- From: Nikola Smolenski smolensk@eunet.yu Date: 2008/12/6 Subject: Re: [Wikitech-l] Bring your language to Commons To: Wikimedia developers wikitech-l@lists.wikimedia.org
On Saturday 06 December 2008 17:49:04 Lars Aronsson wrote:
New user accounts on Wikimedia Commons automatically get a greeting from [[User:Wikimedia Commons Welcome]]. However, this greeting is in English and not all users speak English. At the top of the message there is a list of links to translations in other languages, but I think there is a better way.
Since most new user accounts on Commons (about two thirds) are created by SUL, and arrive through a link that specifies the uselang= parameter, wouldn't it be very easy to set the user preference for user interface language from the uselang parameter when the account is created by SUL?
The greeting template (and other templates, such as deletion requests) could then access the user's interface language setting through a {{USELANG}} magic word, and present the corresponding translation.
This way, new Swedish speaking users (who typically arrive from the Swedish Wikipedia, one that doesn't allow local uploads) could be guided to the Swedish language village pump and find a community there.
This perhaps isn't directly related to your initial query, but I was thinking along similar lines on how to make MediaWiki more internationalized.
MediaWiki is, of course, an excellently internationalized piece of software already. It works excellently with a lot of languages - but what it lacks is the ability to work with more languages at the same time. This is very important on Commons or Meta.
The first step would be to make uselang sticky (or to create a new parameter, for example 'forcelang'), as is the case now with 'variant'. Right now, when someone comes to http://commons.wikimedia.org/?uselang=sr everything is displayed in Serbian, properly, but when he/she clicks on "Log in / create account", the interface goes back to English and someone who doesn't know English can't create the account. But if you go to f.e. http://zh.wikipedia.org/w/index.php?title=%E9%A6%96%E9%A1%B5&variant=zh-... you will see that variant parameter is "inherited" by the links on the page, and whenever you go on the wiki you will remain in the same variant. If uselang would work in the same way, that's one MAJOR improvement already. Since a system for doing this with 'variant' already works, I hope this wouldn't be too hard to do.
And then, what you say. But there exists one caveat - caching. More on this in some future email :)
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi!
How about demanding from foundation to allocate some part of latest usability improvement grant/resources (http://wikimediafoundation.org/wiki/Press_releases/Wikipedia_to_become_more_...) to solve at some of Commons problems?
As for user language: see comments in similar request about user's gender (https://bugzilla.wikimedia.org/show_bug.cgi?id=13040), which also affect quality of MediaWiki localizations.
Eugene.
On Sat, Dec 6, 2008 at 8:49 AM, Lars Aronsson lars@aronsson.se wrote:
New user accounts on Wikimedia Commons automatically get a greeting from [[User:Wikimedia Commons Welcome]]. However, this greeting is in English and not all users speak English. At the top of the message there is a list of links to translations in other languages, but I think there is a better way.
Since most new user accounts on Commons (about two thirds) are created by SUL, and arrive through a link that specifies the uselang= parameter, wouldn't it be very easy to set the user preference for user interface language from the uselang parameter when the account is created by SUL?
The greeting template (and other templates, such as deletion requests) could then access the user's interface language setting through a {{USELANG}} magic word, and present the corresponding translation.
This way, new Swedish speaking users (who typically arrive from the Swedish Wikipedia, one that doesn't allow local uploads) could be guided to the Swedish language village pump and find a community there.
-- Lars Aronsson (lars@aronsson.se) Aronsson Datateknik - http://aronsson.se
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Eugene Zelenko wrote:
How about demanding from foundation to allocate some part of latest usability improvement grant/resources (http://wikimediafoundation.org/wiki/Press_releases/Wikipedia_to_become_more_...) to solve at some of Commons problems?
We probably won't get to much Commons-specific stuff in there, but we'll see what sub-projects come up.
As for user language: see comments in similar request about user's gender (https://bugzilla.wikimedia.org/show_bug.cgi?id=13040), which also affect quality of MediaWiki localizations.
Will social gender (often, but not always aligned with biological sex) always track with grammatical gender?
What are the cascading implications of user gender on localization (adjective agreement in Romance languages, verb agreement in Semitic languages) and what technical requirements would be imposed?
- -- brion
Hi,
I never liked a bot to welcome new users. Isn't it much better to do it by hand? So people also have a contact to go to with qeustions.
Hi!
On Mon, Dec 8, 2008 at 9:55 AM, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Eugene Zelenko wrote:
How about demanding from foundation to allocate some part of latest usability improvement grant/resources (http://wikimediafoundation.org/wiki/Press_releases/Wikipedia_to_become_more_...) to solve at some of Commons problems?
We probably won't get to much Commons-specific stuff in there, but we'll see what sub-projects come up.
Will be good idea to find old e-mail to wikitech-l from Brianna Laugher with Commons requirements since most of the requests still not implemented :-(
For example, unsupported categories translation already used for Commons bad publicity on Russian Wikipedia.
As for user language: see comments in similar request about user's gender (https://bugzilla.wikimedia.org/show_bug.cgi?id=13040), which also affect quality of MediaWiki localizations.
Will social gender (often, but not always aligned with biological sex) always track with grammatical gender?
I hope so :-)
What are the cascading implications of user gender on localization (adjective agreement in Romance languages, verb agreement in Semitic languages) and what technical requirements would be imposed?
Messages should be similar to GRAMMAR (for example GENDER). So sentences such as "User uploaded" could be more correctly translated as "Участник загрузил/Участница загрузила" on Russian or "Удзельнік загрузіў/Удзельніца загрузіла" on Belarusian. Same thing for Polish/Ukrainian and most likely for other Slavic languages.
Gender settings could be also used in Babel extension and user boxes (currently uses parameters for this purpose).
- -- brion
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkk9X4EACgkQwRnhpk1wk44/AACgu3otzh0dqTkIZRi/W5VGbPfn 9sIAmwbir/irI6iViQHWAZ9GgrSdVckM =GE4z -----END PGP SIGNATURE-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Eugene.
On Mon, Dec 8, 2008 at 12:55 PM, Brion Vibber brion@wikimedia.org wrote:
Will social gender (often, but not always aligned with biological sex) always track with grammatical gender?
I believe there are some languages with more complicated gender systems than just male/female. On the other hand, getting just the male/female/unknown distinction right would be a huge improvement for a lot of languages, so it's probably worth it to do just that.
If there are significant other uses of gender in some languages, we might consider offering different preferences for them somehow. So for instance, if the hypothetical language Zulitutsi used different verbs for people who were above or below the age of 30, we could add an extra option when either the interface language *or* the user language is Zulitutsi, "Are you above the age of 30?" This could then be handled in the same framework as gender generally (see below for thoughts on that). Of course, a Zulitutsi speaker on enwiki would then find that almost all other users would fall back to the "unknown" case, but that's acceptable.
I would wait for actual use-cases to come up to bother with this, though. We should just make sure that nothing in the basic framework really strictly assumes a male/female/unknown trichotomy.
What are the cascading implications of user gender on localization (adjective agreement in Romance languages, verb agreement in Semitic languages) and what technical requirements would be imposed?
You'd likely need to write messages like "Automatically block the last IP address used by this user, and any subsequent IPs {{#gender:$1|he tries|she tries|they try}} to edit from", where $1 is the *username* of the affected user. This could be handled the way we handle plurals right now, no huge deal in that sense: things like verb/adjective agreement would come free, since they'd just be manually specified in the messages. If there are more genders somehow, those could be dealt with the same way as with plurals (specify that in the Language class somehow).
The difficulty here is of course that the genders of all users would have to be stored in the database, and every call to #gender would require a query. In particular, for many languages this would require a query for every link to a user page (of a user who exists). We would have to batch these somehow; that might be the only tricky part of writing this. Most likely we'd want to store this as a new field, not in user_options, because we'd be fetching it pretty often when we wouldn't want the rest of the user's options.
Note that I made the first argument to {{#gender:}} a username, not an actual gender. The latter would be much, much more invasive, because it would require every single message that could possibly use the gender of a particular user to pass that gender in as a parameter, which would be a huge mess. It's better from a functionality/code cleanliness point of view to accept the username as an argument and treat initialization of the gender as an optimization.
On the other hand, this might have serious performance implications if users begin spamming genders everywhere (as is likely). If some way could be contrived that we wouldn't mind retrieving the gender of hundreds of (random and unpredictable) users per request, that would be great. In principle it's little enough info that we could easily cache it locally on all the app servers, but that seems like a lot of effort. We might want to initially be optimistic and just fetch from the database, precaching with batch queries where appropriate, and see if it becomes a problem. We could add it as an option first, off by default, and try enabling it gradually on large wikis to see if it becomes a problem. Fetching unbatched genders from memcached would likely be a good idea (but large batches should likely still go to the DB so they can be fetched all at once).
You'd need to special-case the User namespace, undoubtedly, because I doubt we want to support parser functions in namespace names, but pretty much everything else should be possible to handle by "just" the addition of that one parser function and the appropriate database field.
Hoi, When we are to support genders or other personal aspect that can be reflected in the user interface, we can ask everyone for this information. Dependent on the answer people will be treated as per the provided information in those languages where gender makes a difference.
Until the user preferences allow you to enter this information, it does not make sense to change the Internationalisation and the Localisation of the many languages that are supported in Betawiki. In the mean time there are many other issues that deal with Internationalisation that need to be solved. These include issues with RtL support, anyway it is a long list in Bugzilla. Thanks, GerardM
2008/12/8 Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
On Mon, Dec 8, 2008 at 12:55 PM, Brion Vibber brion@wikimedia.org wrote:
Will social gender (often, but not always aligned with biological sex) always track with grammatical gender?
I believe there are some languages with more complicated gender systems than just male/female. On the other hand, getting just the male/female/unknown distinction right would be a huge improvement for a lot of languages, so it's probably worth it to do just that.
If there are significant other uses of gender in some languages, we might consider offering different preferences for them somehow. So for instance, if the hypothetical language Zulitutsi used different verbs for people who were above or below the age of 30, we could add an extra option when either the interface language *or* the user language is Zulitutsi, "Are you above the age of 30?" This could then be handled in the same framework as gender generally (see below for thoughts on that). Of course, a Zulitutsi speaker on enwiki would then find that almost all other users would fall back to the "unknown" case, but that's acceptable.
I would wait for actual use-cases to come up to bother with this, though. We should just make sure that nothing in the basic framework really strictly assumes a male/female/unknown trichotomy.
What are the cascading implications of user gender on localization (adjective agreement in Romance languages, verb agreement in Semitic languages) and what technical requirements would be imposed?
You'd likely need to write messages like "Automatically block the last IP address used by this user, and any subsequent IPs {{#gender:$1|he tries|she tries|they try}} to edit from", where $1 is the *username* of the affected user. This could be handled the way we handle plurals right now, no huge deal in that sense: things like verb/adjective agreement would come free, since they'd just be manually specified in the messages. If there are more genders somehow, those could be dealt with the same way as with plurals (specify that in the Language class somehow).
The difficulty here is of course that the genders of all users would have to be stored in the database, and every call to #gender would require a query. In particular, for many languages this would require a query for every link to a user page (of a user who exists). We would have to batch these somehow; that might be the only tricky part of writing this. Most likely we'd want to store this as a new field, not in user_options, because we'd be fetching it pretty often when we wouldn't want the rest of the user's options.
Note that I made the first argument to {{#gender:}} a username, not an actual gender. The latter would be much, much more invasive, because it would require every single message that could possibly use the gender of a particular user to pass that gender in as a parameter, which would be a huge mess. It's better from a functionality/code cleanliness point of view to accept the username as an argument and treat initialization of the gender as an optimization.
On the other hand, this might have serious performance implications if users begin spamming genders everywhere (as is likely). If some way could be contrived that we wouldn't mind retrieving the gender of hundreds of (random and unpredictable) users per request, that would be great. In principle it's little enough info that we could easily cache it locally on all the app servers, but that seems like a lot of effort. We might want to initially be optimistic and just fetch from the database, precaching with batch queries where appropriate, and see if it becomes a problem. We could add it as an option first, off by default, and try enabling it gradually on large wikis to see if it becomes a problem. Fetching unbatched genders from memcached would likely be a good idea (but large batches should likely still go to the DB so they can be fetched all at once).
You'd need to special-case the User namespace, undoubtedly, because I doubt we want to support parser functions in namespace names, but pretty much everything else should be possible to handle by "just" the addition of that one parser function and the appropriate database field.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Dec 9, 2008 at 2:42 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, When we are to support genders or other personal aspect that can be reflected in the user interface, we can ask everyone for this information. Dependent on the answer people will be treated as per the provided information in those languages where gender makes a difference.
Until the user preferences allow you to enter this information, it does not make sense to change the Internationalisation and the Localisation of the many languages that are supported in Betawiki.
Obviously not. First the feature would need to be implemented, including the user preference. This would probably include at least one language being converted to use the system (maybe partially) as a test case. Then the feature would be rolled out and translators would be advised to implement it for their language if appropriate.
In the mean time there are many other issues that deal with Internationalisation that need to be solved. These include issues with RtL support, anyway it is a long list in Bugzilla.
Are you suggesting that these other issues should be higher-priority than genders? If so, why?
Hoi, As long as the user preferences do not allow people to enter their gender in order to have improve the Internationalisation and the following Localisation, the other things that do not have a prerequisite have priority for the people who Internationalise or Localise. Once this prerequisite is met it will have to compete with the other things that need doing. It takes developers to make this happen.
I do welcome any and all developers to make this and the other Internationalisation issues disappear. But do appreciate that once new features are programmed, it still takes people to create the localisation that makes use of it. For the people who localise, the development, the Internationalisation is a prerequisite. Thanks, GerardM
2008/12/9 Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
On Tue, Dec 9, 2008 at 2:42 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, When we are to support genders or other personal aspect that can be reflected in the user interface, we can ask everyone for this
information.
Dependent on the answer people will be treated as per the provided information in those languages where gender makes a difference.
Until the user preferences allow you to enter this information, it does
not
make sense to change the Internationalisation and the Localisation of the many languages that are supported in Betawiki.
Obviously not. First the feature would need to be implemented, including the user preference. This would probably include at least one language being converted to use the system (maybe partially) as a test case. Then the feature would be rolled out and translators would be advised to implement it for their language if appropriate.
In the mean time there are many other issues that deal with Internationalisation that need to be solved. These include issues with RtL support, anyway it is a long list
in
Bugzilla.
Are you suggesting that these other issues should be higher-priority than genders? If so, why?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Dec 9, 2008 at 9:33 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
As long as the user preferences do not allow people to enter their gender in order to have improve the Internationalisation and the following Localisation, the other things that do not have a prerequisite have priority for the people who Internationalise or Localise.
Obviously part of the feature would be to allow people to specify their gender. That would have to get implemented along with the rest of the feature, if this were done. Otherwise it would be useless, that's obvious. I don't understand your objection.
Hoi, I do not object. There is a prerequisite, get it out of the way. Then get at the Internationalisation, the Localisation. Thanks, GerardM
2008/12/9 Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
On Tue, Dec 9, 2008 at 9:33 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
As long as the user preferences do not allow people to enter their gender
in
order to have improve the Internationalisation and the following Localisation, the other things that do not have a prerequisite have
priority
for the people who Internationalise or Localise.
Obviously part of the feature would be to allow people to specify their gender. That would have to get implemented along with the rest of the feature, if this were done. Otherwise it would be useless, that's obvious. I don't understand your objection.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi!
Gender was used as feature example similar to extracting user-preferred language.
Sure, for Commons user-preferred language is much more critical since it'll exclude admins guess game when using templates on particular user talk page.
I think categories translation and their usage in search will greatly improve value of Commons for non-English speakers.
Eugene.
On Tue, Dec 9, 2008 at 6:17 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Tue, Dec 9, 2008 at 2:42 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, When we are to support genders or other personal aspect that can be reflected in the user interface, we can ask everyone for this information. Dependent on the answer people will be treated as per the provided information in those languages where gender makes a difference.
Until the user preferences allow you to enter this information, it does not make sense to change the Internationalisation and the Localisation of the many languages that are supported in Betawiki.
Obviously not. First the feature would need to be implemented, including the user preference. This would probably include at least one language being converted to use the system (maybe partially) as a test case. Then the feature would be rolled out and translators would be advised to implement it for their language if appropriate.
In the mean time there are many other issues that deal with Internationalisation that need to be solved. These include issues with RtL support, anyway it is a long list in Bugzilla.
Are you suggesting that these other issues should be higher-priority than genders? If so, why?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Aryeh Gregor wrote:
I would wait for actual use-cases to come up to bother with this, though. We should just make sure that nothing in the basic framework really strictly assumes a male/female/unknown trichotomy.
What are the cascading implications of user gender on localization (adjective agreement in Romance languages, verb agreement in Semitic languages) and what technical requirements would be imposed?
You'd likely need to write messages like "Automatically block the last IP address used by this user, and any subsequent IPs {{#gender:$1|he tries|she tries|they try}} to edit from", where $1 is the *username*
I think you're assuming on the syntax the male/female/unknown trichotomy you wanted to avoid.
IMHO it should be: "block any subsequent IPs {{#gender:$1|male=he tries|female=she tries|default=they try}} to edit from" Now, the order isn't hardcoding the Zulitutsi gender.
On Wed, Dec 10, 2008 at 5:28 PM, Platonides Platonides@gmail.com wrote:
I think you're assuming on the syntax the male/female/unknown trichotomy you wanted to avoid.
No, because the semantics of the arguments would be language-specific. Compare to {{plural:}}. In English, and by default for other languages, {{plural:n|x|y}} will print x if n = 1, y if n != 1. On the other hand, in Russian {{plural:}} takes three arguments (in addition to the number). {{plural:n|x|y|z}} will apparently, according to the comments, result in x if n = 1, 21, 31, ...; y if n = 2, 3, 4, 22, 23, 24, ...; and z otherwise. Likewise {{#gender:}} could take varying arguments with varying semantics in different languages.
Something else occurs to me, though: it might need to accept a list of users as well. (The names could be delimited by some prohibited character like /.) Different languages have different conventions about when to use masculine and feminine for groups of users. I can't think of a message where this would be needed, but it's something to keep in mind if anyone takes a stab at this.
wikitech-l@lists.wikimedia.org