Last modified: 2011-01-25 00:29:35 UTC
Have a single login on all wikimedia projects. See http://meta.wikimedia.org/wiki/Single_login
Note that this isn't just a technical problem; duplicate names need to be dealt with in some way.
The code is available, now we need a policy how to handle duplicate accounts. Consider two accounts from different wikis to be merged if the account name is the same and either * the passwords are identical * email address is identical * one of the accounts has not been used for >3 months and has no edits What to do with duplicates that can't be merged? Force both user to get a new nick?
why not change both or prefixed/suffixed them with the lang code (en, de, fr, etc.) The sole thing is to convert the new name in the whole database to keep modification history
I suppose that the way to start this process going, is to make all new accounts, create an account in all of the projects / stop the new user from making a username that conflicts with other users... and deal with it case by case, maybe the person is making the same username in a new wiki.. in which case that person should be allowed to enter the password for all of the old wiki users, and then that user gets to choose to make a new account.. So, I guess what I'm saying is, new accounts are easier to deal with than the old accounts, so it should be possible to enable this for new accounts first, and then gradually get other users to make all their passwords the same... This would probably take about a year to get a good portion of the people converted.. and then, send email to the people who have inactive accounts? then have a class of "dichodomy?? " users? and or do the database conversion of all the wiki links that contain the user page.. Tons of work for the server... and annoying to the users... but hopefully minor Sysop accounts are the most important..
(In reply to comment #1) > Note that this isn't just a technical problem; duplicate names need to be dealt with in some way. Using full email address as an account is a good idea. And people don't need to remember extra names.
Proposed approach, based in part on discussion with JeLuF a while ago, is at http://meta.wikimedia.org/wiki/Single_signon_transition . kissall, requiring use of email addresses to sign on and displaying different names is a mess. Displaying email addresses unnecessarily is a privacy and spam problem, so that's not an option. Personally, I strongly dislike sites which want an email address (often for their spam lists) as a login. It doesn't help with ID that much - you still have to remember which of your email addresses you used.
I understand your concerns. My bank is even requiring my SSN as login name. :( I guess usually there is no a panacea for any problem. There is always tradeoff for any solution. We can list available solutions and their advantages as well as disadvantages. And let more people to express their opinions. Then ,we can reach some kind of agreement and do it. Otherwise, there are only worrying and concerns and no progress at all. As you can see, I am also aware of the email spam and privacy problem so I am using this nickname and gmail account to participate in this mailing list. But It does not mean I am not serious for this project. :-) By the way, using only one formal email account to handle all things today seems to be a inappropriate choice. I know many persons around me are using several email accounts to handle difference things with different priority or security levels. In conclusion: For the solution for duplicated email account, we now have at least one disadvantage if we use email address as an account: privacy & spam problem when people using their formal email account to register. However, there may be a workaround: advising users to get a free email account with nickname. (In reply to comment #6) > Proposed approach, based in part on discussion with JeLuF a while ago, is at > http://meta.wikimedia.org/wiki/Single_signon_transition . > kissall, requiring use of email addresses to sign on and displaying different > names is a mess. Displaying email addresses unnecessarily is a privacy and spam > problem, so that's not an option. Personally, I strongly dislike sites which > want an email address (often for their spam lists) as a login. It doesn't help > with ID that much - you still have to remember which of your email addresses you > used.
Note: I've created a new page at http://meta.wikimedia.org/wiki/Single_login which merges and expands on some of the previous discussions on this topic (including that mentioned in Comment #6). Please help improve that page and add any comments you wish to make.
I want to propose to start IMMEDIATELY NOW (crying, yes) with ONE NEW service (of all WikiPedias), where users can register NEW names, which they want to reserve for ALL WIKIPEDIAS. Then, these new usernames will immediately be checked against all existing Wikipedias and - if free - will be pre-registered. If you don't like my idea, please post a well-based argument against my proposal. Thank you. Tom
(In reply to comment #9) > ...where users can register NEW names, which they want to reserve for ALL WIKIPEDIAS. > Then, these new usernames will immediately be checked against all existing > Wikipedias and - if free - will be pre-registered. Sounds great, to prevent even more Namen-conflicts coming up. Good Idea! I'm just not sure how the "create account" on the second Wikipedia then will work (same password, same email...?) but that is probably possible to be solved in some way. Thanks a lot, I like this idea as a first step to solve this problem Fantasy :-)
When it comes to single login, always reserving a name in all projects isn't necessary or the best way to go. Most people just don't use all projects Wikimedia has or will ever host, so there's no point in blocking others from using the same name in different projects and getting the same lack of decent name choices problem AOL Instant Messenger and such have. Can have single login (log in once, login applies to every project you visit) without that. Anyone who wants to stop others from using the same ID in different projects can visit them easily enough (and for those who don want to block others everywhere, in all 600+ projects) we could make that easy enough. Not many of us really need that, though, if only because few of us read a hundred languages - I know I don't (I've only used 20 or so projects).
(In reply to comment #11) > When it comes to single login, always reserving a name in all projects isn't > necessary or the best way to go. Jamesday: I am of a totally different opinion. Good (or bad) names can be like trademarks, they are some part of the intellectual property of a contribution. If I would use for example "Jamesday" somewhere else, for example in a very bad vandalism context, pretending that I am you, this would certainly not please you and you could not do anything against it. Your fame can be permanently damaged and so on. Single-logon ***must allwow to reserve a name in ALL projects at once***, when someone wishes so during his/her first login to a wiki project. The numerous single-logon discussions about reserving or non reserving in all projects bothers me.
(In reply to comment #12) > Good (or bad) names can be like trademarks, they are some part of the > intellectual property of a contribution. Unfortunately, this fails to take into account that some names are more common than others (e. g. jsmith is almost definitely non-unique; even my unusual last name, Granade, is not unique on the Web). Thus, in evaluating the validitity of a single sign-on solution, the number of currently overlapping IDs should somehow be considered. I'd suggest a statistical sample of IDs from WikiPedia:en checked against a list from the other 599 projects. Upon a collision, one could investigate by hand whether the IDs represent the same user or not. I would help with this (not do it by myself), but I don't have access to the appropriate data. > Single-logon ***must allwow to reserve a name in ALL projects at once***, when > someone wishes so during his/her first login to a wiki project. The numerous > single-logon discussions about reserving or non reserving in all projects > bothers me. If you must, make User IDs in the form of something like: cgranade@WikiPedia:en.
(In reply to comment #13) > > Good (or bad) names can be like trademarks, they are some part of the > > intellectual property of a contribution. > I'd suggest a statistical sample of IDs from WikiPedia:en > checked against a list from the other 599 projects. Upon a collision, one could > investigate by hand whether the IDs represent the same user or not. This was already possible by using Kate's Namechecker Tools: you could have entered a name and then checked the presences of this name in all other wiki projects. In addition, the stored email address was checked for equalness between the different wikis, and distinct mail addresses were numered, so I could see, where (supposed) I was registered with the same addresses, and whereelse my account name was used - because of intentional different own mail addresses, or because this was really another person using my log-in name. > If you must, make User IDs in the form of something like: cgranade@WikiPedia:en This is ridiculous (sorry, but my patience for single-user login is at the very end), when I expressly demanded the **same** name in all projects, where it is unused; nobody would like to use such long names as suggested by you. I cannot accept the lengthy discussions any longer, which hasn't brought any movements towards the single-login; nada-zero-rien was achieved in this resprect during the last months. I might be too pushy, yes, I admit, I am. Some called my already a "locomotive", this isn't bad at all. But I am not developer and fully respect the common-sense in the Mediawiki software development. Please check also http://meta.wikimedia.org/wiki/SUL and http://meta.wikimedia.org/wiki/Namecheck (the link to neat Kate's Tool is broken, because her server doesn't serve any longer)
(In reply to comment #13) > If you must, make User IDs in the form of something like: cgranade@WikiPedia:en. Possible solution based on this idea: For instance, my first wiki account is on english Wikipedia as Omegatron. This should then allow me to log onto any other projects using a single login: "Omegatron@Wikipedia:en" (or "enpedia:Omegatron" or some other suitable unique modifier based on which wiki i registered on). en wikipedia is now my "home", but i have a single login name valid for all the rest. If someone else has the same login Omegatron on the german wikipedia, there is no conflict; they can also log onto any other project with Omegatron@Wikipedia.de and are known as simply Omegatron on the german pedia.
(In reply to comment #15) Sorry to double-post. With this proposal, I am still free to register the shorter, more personal name Omegatron on any other wikis that I use frequently, but if I just want to leave a note on de I would use my singlelogin Omegatron@WP:en, or if I got interested in wikitravel but there was already someone else named Omegatron registered there, I could just use Omegatron@WP:en all the time, keeping us distinct. Or whatever. If someone clicked on my "- Omegatron@WP:en" signature on a german discussion, for instance, it would by default just redirect or link to my en user page, since that is my "home". Note that the suffix/prefix/modifier whatever doesn't need to be in the form I am putting it; just an example of a possibility.
> With this proposal, I am still free to register the shorter, more personal name > Omegatron on any other wikis that I use frequently, but if I just want to leave A new single-login scheme must be "KISS" (keep it) short and simple; I fully admit, that all contributions so far has their positive and negative sides; but basically, we a need like Kate's one, which checks, whether a (new) name is free in all other wikis Then, I cannot see a single reason, why this new and unique name cannot be registered immediately in all wikis and blocked for being used in (probably later born) wikis. This is basically my only request. Let's start with this, it is the basis for all proposals, see the synopsis on the page http://meta.wikipedia.org/wiki/SUL . Tom
Why was this filed under "language setup"? Not all Wikimedia projects are simply differently language versions; they are different projects!
There's already too much discussion here but I can't put my comment on Meta because I've been banned. My comment is that I have not been banned on the English Wikipedia, which would not be good if I was actually intending to vandalise.
Hallo! I could see that http://www.wikipage.de/de/index.php?title= and http://www.wikipage.de/en/index.php?title= are using single login but this might be a configuartion issue. There *only one* user interface can be selected. My question is what other issues should be considered, what parameters should be "single" and what "individual" for each wiki. The question arrives because some people would like to use the language interface of the content wiki. There are many other parameters but I suppose that they should not be duplicated all. An optional implementation would be to use somthing similar to the user skin pages but I assume that this would *not* be used by / popular for the majority. Regards Reinhardt [[user:gangleri]]
addition to comment 20 topic: what comes *after* "Single login on all wikimedia projects" There is a *half* workaround regarding the language of the user interface at http://www.wikipage.de/de/index.php/Main_Page . At the moment "anonymous users" will use always the "content language". (Note: I remember a feature request to allow setting [[Special:Preferences]] to anonymous users). Viewing WikiPage with a seccond browser will allow to see (some parts of) the interface in "conten language". I would suggest to have the following options for slecting the interface language: global interface language button: one from the list *including* content language local interface language checkbox: one from the list *including* content language the "local interface language" should overwrite "global interface language". I am not shure if a selector "content language = $..." could be added already to the code and if this belongs to this bug or if another bug should be opened. Regards Reinhardt [[user:gangleri]]
*** Bug 3200 has been marked as a duplicate of this bug. ***
Proposed process for migrating old "single-wiki" logins to "multi- wiki" login. * Disable all single-wiki registration. * Preserve single-wiki logins -- they will continue to work just the same as always. * Create a DB of *ALL* single-wiki names (with their wikis). * Enable every-wiki registration ** When a new every-wiki login is created, it must be checked against the universe of single-wiki names as well as every-wiki names * Migrating single-wiki to every-wiki ** If a single-wiki user has a unique name that is NOT used in any other wiki, it can be automatically migrated to an every-wiki account. The user pages will have to be preserved. ** Allow single-wiki multiple users to create a wiki-logins umbrella *** Under the umbrella, they can demonstrate ownership of a long list of single-wiki logins on multiple wikis "these are all me" *** If they can demonstrate "total ownership" of a desired login name, they can convert the entire umbrella group of wiki logins to the new every-wiki login under the desired name *** Or they can choose a brand new login for converting their umbrella *** The single-wiki logins under the umbrella don't have to be the same. They could be en:wikipedia:john, en:wikibooks:john, fr:wikipedia:jaques. And as long as the user had every existing john account under his umbrella, he could claim the every- wiki:john account. ** If an account is removed from the single-wiki space, new registrations no longer need to check it. *** If the single-wiki account space becomes empty, so much the better *** These "retired" single-wiki names should move to a "retired" list so they are not immediately give out to new multi-wiki users. It would be confusing on fr:wikipedia if Jaques became John and a newbie Jaques were able to register the retired Jaques login name the very next day! * every-wiki logins should also work on bugzilla. --[[user:SV Resolution]]
Is this just an academic discussion about what could potentially be done? It seems to lead nowhere and this bug has been known for far over a year now. It needs urgent action and is annoying as hell! BTW: Anyone noticed that you need to create an additional bugzilla account to access bugzilla?
Implementation for such a feature will require a lot of discussion. Please don't mindlessly bump up the priority; this is not an urgent security hole or bug fix. You need to create a separate account because development work and wiki work are different things.
Two ideas that are kind of complete tangents to current discussions: 1) Allow for OpenID-based authentication in addition to native user accounts. If needed, give OID users a lower permission level. (See: http://openid.net/ or http://en.wikipedia.org/wiki/OpenID) 2) Allow for GnuPG/PGP based authentication- present a random "salt" and challenge the user to sign it, with the server verifying the signature. If needed, give GPG users a lower permission level.
There has been recent discussion about a patch for OpenID on the wikitech-l mailing list: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/19808
Rob Church: > Implementation for such a feature will require a lot of discussion. Please don't mindlessly bump up the priority; this is not an urgent security hole or bug fix. There has already been a lot of discussion. The feature is among the highest asked for for two years or so. It should have highest priority by now. The risk with discussion is not that someone jumps in without discussion, the risk is that noone wants to discuss because they already said their thing several times, and besides this is not going to happen anyway. Apparently you want to keep it that way, because you want 'a lot of discussion' first. And after that? A lot of discussion again? And again? That's the best way to ensure it will really never happen. You may be okay with that, I am not.
(In reply to comment #28) > Rob Church: > > Implementation for such a feature will require a lot of discussion. Please > don't mindlessly bump up the priority; this is not an urgent security hole or > bug fix. > > There has already been a lot of discussion. The feature is among the highest > asked for for two years or so. It should have highest priority by now. The risk > with discussion is not that someone jumps in without discussion, the risk is > that noone wants to discuss because they already said their thing several times, > and besides this is not going to happen anyway. Apparently you want to keep it > that way, because you want 'a lot of discussion' first. And after that? A lot of > discussion again? And again? That's the best way to ensure it will really never > happen. You may be okay with that, I am not. > I find your insinuations offensive. There are practical issues and we need to decide what to do about them. You think you can do a better job...get coding. Remember; only *one* of our developers is paid; the rest do it purely voluntarily. Don't whinge, rather; see what suggestions you can make for implementing this, for detecting conflicting users - and resolving those.
> There are practical issues and we need to decide what to do about them. Well then, make a decision! There have been proposals, they have been discussed, and then new proposals are made. And new proposals. And new discussion. And new discussion. And what is your solution to that? MORE DISCUSSION!!!!! > You think you can do a better job...get coding. > Remember; only *one* of our developers is paid; the rest do it purely voluntarily. So? That means that noone can decide for them what they should do. Fine. It does not mean you can just decide that certain projects need another few centuries of discussion before they can happen. You think you can do a better job...get coding. Don't stop others from doing so instead. > Don't whinge, rather; see what suggestions you can make for implementing this, for detecting conflicting users - and resolving those. I could make suggestions, but they would just end up the same way as all suggestions that already have been made - a bit of discussion, and then tucked away again. And next month the next person says that this would be great to have, and he makes a new proposal, and the same happens. There is no lack of ideas or proposals. There is no lack of discussion. What there is a lack of, is decisions.
How about I just throw out the suggestion right now, to help quell what I think is going to become a big flamewar. It's not a particularly good suggestion, but throwing insults at each other isn't helping. Enabling the feature will not make anybody suddenly be able to log into other wikis without registering. Rather, it will allow a user to "claim" their username across all namespaces. All Wikimedia projects must either 1) not have a user of their name or 2) have the user be able to log into the account, verifying they indeed own the account. In the event there's no conflict, the user will then have to globalize their data, choosing one set of personal information that will be preserved globally. There will not be the ability to "tweak" user information per a project basis. Monobook.css and .js will be preserved. In the event there is a conflict, an interlingual dispute resolution process kicks in. We notify the passive username holder about the conflict through talk page notice and email (if on file), we also compare join dates. If... 1. Passive username holder has no edits - relinquish username automatically in 3 days 2. Passive username holder has < 100(?) edits - relinquish username automatically in a week 3. Passive username has a greater amount - relinquish username automatically after 3 months (mainly to prevent deadlocks) If the user does respond before time runs out, they will bring their cases towards the multilingual Naming Committee, which will decide on a case-by-case basis which user must get a new username. If a username is automatically relinquished, the user data will be held in an archival table. If the user decides to try to log in (log in fails with current hash but passes with the archival hash), then they are directed to a page that will let them choose a new username and rename their user. On a more technical basis, this would entail... 0. Create a 'old_user' table with exact same structure as regular user table 1. Add a 'global_id' column to users table, which is set to null 2. Lock down database 3. Run a script on all databases that will attempt to automatically globalize usernames that exist in only one language. If they are fine, give them a global_id and that's it! 4. Unlock database and enable user globalization A user requests to globalize themself 1. Query all Wikimedia projects for the conflicting usernames 2. Have user attempt to log into the projects that have usernames, if he is successful, mark those username columns and the current username with the same 'global_id' identifier. 3. If, now, all conflicting usernames have the same global_id, you're done. There were non-user-owned accounts in the Wikimedia domain. 1. Send messages to all the non-user-owned accounts. Hopefully for the dormant editors an email was registered 2. Set cron jobs (or lump in with one big cronjob) that will check for the status of all the accounts at the respective times. If all accounts have sunsetted, move all conflicting usernames to the archive table and globalize the requesting user. 3. Someone replied, but finish sunsetting, because eventually these will all have to resolve 4. Depending on the number of people who replied, there may be some big conflicts. All users present their cases to the Naming Committee, which judge which user needs that particular account most. Their decision will cause step 2 for the winning user. If the Naming Committee decides that at least two users have legitimate reasons to keep their username AND neither will rename, the issue will be shelved for half a year, after which both usernames may reapply to the Naming Committee. All usernames in the other projects are locked, to prevent exacerbation of the situation.
It occurs to me that cross-referencing every single Wikimedia project will take quite a bit of time. Anyone have any ideas to mitigate this cost?
Hallo! Single login should come as "a package". This request ahs the most votes ever made for a feature request. To identify the needs please take a look at [[Wikicities:]] http://wikicities.com/wiki/Main_Page still using version 1.4.10 . See also http://games.wikicities.com/wiki/Special:Listusers . Please log in. And select your user preferences. Then find a wiki in a language other then English at http://wikicities.com/wiki/Category:Languages . Please identify yourself what feature are missing. Some remarks on previous comments: - the criteria that user name, email *and* password should be the same in order to identify a *global* user name are not suitable because passwords may differ especially for accounts where this user has additional rigths and changes the password more often; - in my opinion we need to support also *aliases* especially for languages which are not written in lattin; see http://sr.wikipedia.org/w/index.php?title=user:Millosh&redirect=no http://ur.wikipedia.org/w/index.php?title=user:Wisesabre&redirect=no some bugs are marked depending on this Bug 1066: Please add cross-wiki talk page notification. Bug 1552: Feature request: Upload to commons from Wikipedia, Wikibooks, etc. Bug 3525: Cross-wiki watchlists with option for public viewing additional feature requests have been opened which are usefull for single login; I remember Bug 2474: (marked WONTFIX) Change Special:Listusers to show only accounts with edits - maybe the request should be changed "Add a checkbox to Special:Listusers to show only accounts with edits" Bug 3904: disallow user pages and user_talk pages starting with lower case on case sensitive wikis If there are more hundered wiki's in the "project group" as is the case now at the Wikimedia foundation projects / wikis users will not be active at all of them. This is why the user parameters need to be split in more groups *general* parameters as - user name, name, email, alias (?), "prefered" user interface individual parameters to each wiki - active or not - language interface (local, prefered, one of the UI list) - rights - blocks It makes sense to enable both - email notification on changes of the own user *talk* page (available now, configuration issue) - email notification on changes of the own *user* page (if possible including its subpages) -- email notification on chabges of subpages of the own user *talk* page (changes in archives, subpages for special topics etc.) Please note that this requesta has "Product" "Wikimedia web sites". In fact it should be "MediaWiki" "User login/settings" as it is suitable for other installations as well. It needs to handle also "restricted" wiki's as http://wikimediafoundation.org/ and should support also case sensitive wiki's. Because this feature requires many adminidtrative steps it might be a good idea to *provide* an *url* where people interested in single login can query the database and see if their user name is used also in other projects. Viewing the results they may have time to thing about. For projects using languages based on the Latin alphabet these accounts can be found with an existing tool (where the search in 50 languages is hardcoded): http://vs.aka-online.de/cgi-bin/globalwpsearch2.pl?project=wiktionary&timeout=120&minor=1&search=user:Angela http://vs.aka-online.de/cgi-bin/globalwpsearch.pl?timeout=120&minor=1&search=user:Angela A more important thing would be to *provide* an *url* where changes to actual database model are discussed. This would make it more simple to understand restrictions and implications. Best regards reinhardt [[user:gangleri]]
For the information of whoever it was I was arguing with earlier, I actually went and read all the Meta pages related to this, and I personally like one of them in particular; entitled "Single login specifications" or similar.
It might be a good idea to distingish between - "Sign in" to a particular wiki and "Single sign in" to all wiki's in a group which are related to creating an account / accounts - globally unique user id (GUID) - "Log in" and "Single log in" login after an account has / accounts have been created I assume that the most embarrassing issue is that users have to *log* in after each / most software updates. Making a distinction between "Sign in" and "Log in" can avoid automatic "Sign in" to *all* projects discussed earlier. The distinction can make the process more flexible and MediaWiki could avoid the "automatism" "Signing in" / "Logging in" users at wiki's without their will / consent.
No, I'd say make it far less complicated. If you log into one Wikimedia wiki, you should be logged into all the others. Principle of least surprise and all that.
(In reply to comment #36) > No, I'd say make it far less complicated. If you log into one Wikimedia wiki, > you should be logged into all the others. Principle of least surprise and all that. I'd agree with this but if it is not too difficult to code I would prefer a radio button selection offering *Log into all Wikimedia wikis *Log into this wiki only The first option should be the default and "Wikimedia wikis" should be linked to a list of all the wikis that this would log you on to. The log out options would be the same. A possible third option would be *Log into custom set of wikis. This would be the list of Wikimedia wikis that you would be logged into but with a checkbox next to each one. (I suspect this might be difficult to code though?). All the defaults would ideally be changeable in preferences.
Not necessarily difficult, but damn fiddly, and IMO, pointless. Why would you not want to be logged into them all, especially if we take (I think it's Erik's) suggested implementation for negotiating conflicting accounts.
(In reply to comment #38) > ... Why would you > not want to be logged into them all, especially if we take (I think it's Erik's) > suggested implementation for negotiating conflicting accounts. There might be different reasons: - please take a look at [[meta:Special:SiteMatrix]]; you probably will see projects using fonts which display as question marks, squares etc.; - some sites are sending non-Wikimedia foundation cookies; this might irritate users; - there might be countries where users would have "''difficulties''" if they are displayed as users / contributors at sites in certain languages (this sounds very strange; I lived many years in a country with a totalitary political system and I know what I am talking about)
(In reply to comment #31) > Enabling the feature will not make anybody suddenly be able to log into other > wikis without registering. Actually, my proposal would allow you to log into other wikis without registering.
*minor detail* A user name as "Patrick (Hannover)" will render as "(Patrick (Hannover" at RTL wikies. Similar rendering applies to all user names ending with characters having directionality boundary neutral due to the bidirectional algorithm. Symmetrical examples can be given also for usernames containing RTL characters: RTL: אביב (1973) LTR: אביב (1973) I assume that beside the field for the user name MediaWiki will need also three radio boxes: a) append ‎ b) append ‏ c) unchanged (default). best regards reinhardt [[user:gangleri]]
*** Bug 8034 has been marked as a duplicate of this bug. ***
This feature would be great to have. > I assume that beside the field for the user name MediaWiki will need also three > radio boxes: a) append ‎ b) append ‏ c) unchanged (default). Would this be that hard to do?
Two cents: Every month that passes makes the "duplicates" problem worse.
(In reply to comment #44) > Two cents: Every month that passes makes the "duplicates" problem worse. These sorts of comments are not helpful. At all. Don't make them. "Single user login" is being worked on. It's not a simple issue. It's not even a a hard issue. It's a very complicated issue, because it's more than one set of changes.
*** Bug 9261 has been marked as a duplicate of this bug. ***
Re Connel McKenzie: Ignore the duplicates problem, just keep all existing accounts as is and ask people who want universal logins to open new accounts. So the technical challenge then is dealing with two types of accounts: single project vs. universal.
I wonder what part of ""Single user login" is being worked on" isn't understood, they aren't gonna keep all existing accounts as is since they've already done most of the work (or at least a lot of it).
http://bugzilla.wikimedia.org/show_bug.cgi?id=9604 <-- This would partially resolve this #57 bug.
If anyone hasn't heard yet, and is viewing or watching this bug. Brion (and some other devs?) have enabled a beta version on http://test.wikipedia.org/wiki/Special:MergeAccount . Check it out! :-)
I tried the demo and have one suggestion: I don't know what algorithm is used to determine the "home wiki", but I got the one I wouldn't prefer. (I know I can change it later, but it's unnecessary step.) I'd suggest to have default home wiki that one on which user registered first, because usually the first registered wiki is the most often used therefore the home.
The algorithm prefers sysop/bureaucrat/steward accounts to any others. In the event of a tie (either multiple or no privileged accounts), it chooses the wiki with the highest edit count, probably a better metric than signup date. You can always change your home wiki if this initial guess is wrong, which it inevitably will be in many cases. I'm assigning this bug to Brion for clarity, if he doesn't mind, since he's working on it (among many other things, alas). Code is all in Subversion at http://svn.wikimedia.org/svnroot/trunk/extensions/CentralAuth . It can be viewed online at: http://svn.wikimedia.org/viewvc/trunk/extensions/CentralAuth
``You can always change your home wiki if this initial guess is wrong, which it inevitably will be in many cases.'' The problem will comes when the initially-guessed home wiki account is owned by another person. I think the person who register first should own that username on the unified wikimedia sites. Imagine, what if the wikimedia sites have been unified ever since the sites are first established long time ago (that their accounts have never been separated), the person who register first will own that username on all of the wikimedia sites. The person who come after will unable to use the registered username, and have to choose their alternate username. This logic should also apply on current wikimedia sites, after it have been unified.
Please note that there is a lot of dicussion taking place on Wikitech-l, so please correspond there, if you can, so you get more answers and so that your questions aren't repeated. Thanks!
(In reply to comment #56) > Please note that there is a lot of dicussion taking place on Wikitech-l, so > please correspond there, if you can, so you get more answers and so that your > questions aren't repeated. Thanks! > Could you please provide me the links to the discussion about this issues (the conflict resolution)?
(In reply to comment #57) > (In reply to comment #56) > > Please note that there is a lot of dicussion taking place on Wikitech-l, so > > please correspond there, if you can, so you get more answers and so that your > > questions aren't repeated. Thanks! > > > Could you please provide me the links to the discussion about this issues (the > conflict resolution)? Umm... it's a mailing list... a pretty well-known mailing list. :-) http://lists.wikimedia.org/mailman/listinfo/wikitech-l (and view the archives or subscribe or w/e)
> > Umm... it's a mailing list... a pretty well-known mailing list. :-) > http://lists.wikimedia.org/mailman/listinfo/wikitech-l (and view the archives > or subscribe or w/e) > Yes, I've already searched in the archives, but that doesn't help :( Is there any discussion about this in the wiki pages?
Please don't use this bug to ask general questions -- every post here gets e-mailed to the dozen or so people watching the bug. For docs see http://meta.wikimedia.org/wiki/Help:Unified_login and the code notes: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/CentralAuth/
Pile-on support; a huge functionality.
This feature is now live for sysops only on all Wikimedia projects through [[Special:MergeAccount]]. Some details are still missing: rename of global users, one talk page across projects, inheritance of user settings (UI language, watchlist settings, etc.). The details are however not part of this feature request. I guess this issue can be closed as soon as other registered users will also be able to convert their account to a global account.
According to, http://lists.wikimedia.org/pipermail/wikitech-l/2008-April/037286.html Is it possible for this bug to be changed in scope to unify only on individual language? == Unify by language == To merge the user accounts by language. Example, * user123 on fr.wikipedia.org, fr.wiktionary.org, fr.wikibooks.org, fr.wik*.org will be merged * user123 on ja.wikipedia.org, ja.wiktionary.org, ja.wikibooks.org, ja.wik*.org will be merged * user123 on fr.wikipedia.org and ja.wikipedia.org won't be merged, so that user123 at fr.* and user123 at ja.* will be separated. 1. This will make much less conflict than unifying all language. 1.1 Most conflicts in non-english wiki is the conflicting of user between diffenrent language. 1.2 Even on the first-come-first-serve (FCFS) basis, this still result in few conflict. While it look very unreasonable when the first registered user will suddenly gain control for wikis on all languages, it is more reansonble when FCFS is used only among the same language, since it cover not too much wiki websites. 2. Most users will not be likely to actively edit non-trivial contents in more than one or two languages. And it does not take too much energy for one person to maintain their user account/preference/watchlist in only two or three languages. 3. Most users will tend to agree to loss their username (if conflict with others) on their non-primary language that they not actively edit or contribute only trivial contents. 4. Even the new registered user (after this unify) will only get the accounts of the same username on wikis of the same language. They will not get accounts on all languages. Why let FCFS users to reserve the control on wikis of hundred languages that most of them are unlikely to edit or taking any attention? Unifying all languages is an overuse. === Account in wiki commons === The only problem is that, wiki commons will be merged with which language? * commons --> en.*, fr.*, ja.* ? * Let the person who own user account on commons to choose the language that will be merged with commons? * Or the person on the language with most edit-count will get username on commons? * Or let the users to negotiage for the agreement by themselves?
The suggestion breaks down for the multilingual wikis like Commons, Meta, and MediaWiki.org, which many people from a variety of languages use. That forces accounts on any wiki to be created on wikis like Commons if we want this to work properly. That, in turn, means all the conflicts will arise anyway. Simplicity dictates that we want a single system that just works for everyone. The number of conflicts you're going to avoid is small enough to not be worth the complexity of having to sign up separately for each language and for the multilingual ones. Conflicts are a one-time thing, the rest is not. Besides, all of this was decided something like three or four years ago. You're way, way too late to get any sweeping changes through. These discussions have all already been had, and they're over. SUL will unify accounts on all public wikis (at least).
Now enabled for everybody (opt-in). Big thanks to Tim for doing *lots* of fixups over the last couple months, and Werdna for lots of help with the cross-domain global cookies & global groups additions, and everybody else who's helped with testing and translations and fixes!
(In reply to comment #65) > Now enabled for everybody (opt-in). Woo! Thanks everyone!
