I can understand the rationale for this policy, but it _is_ ethnocentric, and it counters the problem from the wrong side, if you know what I mean. Instead of trying to fix the problem, they try to remove it.

Gerard, The problem does indeed occur symmetrically, and while I phrased my reply in terms of making non-Latin names unambiguous on native-Latin-script Wikipedia editions, you might want to re-read my comment, and notice the bit that said: > Of course, to avoid any appearance of linguistic imperialism, the same > facility should be available for users with Latin-script names to add > transliterations in other scripts. > > > > -- Neil

The SUL is almost a year late as it is. All issues have been discussed at length at the time. Postponing it now it not really an option. There is also no capacity to come up with a technical solution. There is even no consensus as to what the problem is.

And how much mass vandal robots did you have before discuting and accepting this policy (if it has been ever discussed and accepted ;)) ?

If you have a bot making mass vandalizing, if the pseudo will be latin or non latin won't make any difference.

And by the way for bot generated pseudo it exists a feature ;).

The probleme here, for my point of view, is totally different. In the five pillars we can read "Wikipedia is free content that anyone may edit" exept vandals of course, and your policy is going against this as you block non latin pseudo before they began editing, even if they would be a good editor.

The en.WP Username policy has been changed. http://en.wikipedia.org/w/index.php?title=Wikipedia:Username&curid=1686…

> thereby denying that many of the reasons why this policy was put in > place is seriously wrong. > > I have to say I am increasingly upset by this affair. > > Thanks, > GerardM

en.WP is not the primary Wikipedia for many wikimedia editors. These usernames *are* in the primary character set of the users home wiki. I think it is perfectly reasonable to expect to not be blocked just because Wikimedia adopts SUL. Bascially what this boils down to is someone who today edits as an IP without harrassment will be blocked after SUL as soon as an en.WP admin spots them on RC. This will happen without the editor doing anything differently on their end. There is strong support for SUL throughout all communtities, but I cannot support going live with it if large chunks of the wikimedia community will be locally blocked without warning on any particular wiki. If en.WP does not wish to adjust thier policies to this mew development perhaps en.WP can be left out of SUL. Is it possible for en.WP to keep their own user database while all other wikis use a shared database? Birgitte SB

Neil Harris schreef: > Birgitte SB wrote: > > > > > >> en.WP is not the primary Wikipedia for many wikimedia >> editors. These usernames *are* in the primary >> character set of the users home wiki. I think it is >> perfectly reasonable to expect to not be blocked just >> because Wikimedia adopts SUL. Bascially what this >> boils down to is someone who today edits as an IP >> without harrassment will be blocked after SUL as soon >> as an en.WP admin spots them on RC. This will happen >> without the editor doing anything differently on their >> end. >> >> There is strong support for SUL throughout all >> communtities, but I cannot support going live with it >> if large chunks of the wikimedia community will be >> locally blocked without warning on any particular >> wiki. If en.WP does not wish to adjust thier policies >> to this mew development perhaps en.WP can be left out >> of SUL. Is it possible for en.WP to keep their own >> user database while all other wikis use a shared >> database? >> >> Birgitte SB >> >> >> >> >> >> >> > Absolutely. > > Different-script blocking on en: must therefore stop as soon as SUL is > implemented. > > But, since human-readable usernames are essential to managing the wiki > system, and for many people names not in their native script are not > human-readable, there must necessarily be some sort of solution to the > name-incomprehensibility problem before SUL goes live. > > The truename + nickname idea looks to me like the favourite at the > moment. I definitely support it, with the provisos that: > > * truenames _and_ nicknames need to be made globally unique within the > single SUL namespace, otherwise they will present new opportunities for > misdirection (eg. nick of one user is the same as the truename of > another and vice versa, or that on another different-script wiki...) > * that each truename or nickname have characters only from a single > script system (although they will of course in general have different > script systems from one another, because that's the whole point) > * that the anti-spoofing code be used to filter both (which may need > some overdue improvements in the anti-spoofing algorithm to be put in > place, which I've got on the back burner already anyway) > > I would also suggest, at the risk of further controversy, that having an > appropriate nick be made compulsory if you intend to use your account to > edit in a wiki with a default script different from that of your username. > > Perhaps we could put in place some sort of human-driven wiki-based > please-translate-my-name-into-your-script service for this, or simply > generate a (also globally unique) machine-generated ID until users > create an appropriate nick, with regular nag messages to remind them to > do so? > > -- Neil > > > > Hoi, You cannot have the cake and eat it too. All languages and scripts that we have are human readable. The notion that they are not is brain dead. The idea that nicks have to be unique too will be next to impossible to implement. Again, when a user is created in a Latin script, and he does "evil" things, you will have to check the talk page / history to find in what way you want to impose sanctions. This is no different from people with a user in another script. Again, I think that the suggestion of forcing to have people change their name is the wrong way to go. I am dead against it. It is discrimination pure and simple. Thanks, GerardM