Last modified: 2011-01-25 00:29:35 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 57 - Single login (Unified login) on all wikimedia projects
Single login (Unified login) on all wikimedia projects
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: Highest enhancement with 115 votes (vote)
: ---
Assigned To: Brion Vibber
http://meta.wikipedia.org/wiki/SUL
: crosswiki
: 3200 8034 9261 (view as bug list)
Depends on: 1180
Blocks: 1066 3525 9604 1552
  Show dependency treegraph
 
Reported: 2004-08-15 16:38 UTC by elian
Modified: 2011-01-25 00:29 UTC (History)
30 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description elian 2004-08-15 16:38:16 UTC
Have a single login on all wikimedia projects.

See http://meta.wikimedia.org/wiki/Single_login
Comment 1 Brion Vibber 2004-08-24 06:05:33 UTC
Note that this isn't just a technical problem; duplicate names need to be dealt with in some way.
Comment 2 JeLuF 2004-08-27 06:06:14 UTC
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? 
Comment 3 xmlizer 2004-08-27 10:00:41 UTC
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
Comment 4 Aaron Peterson 2004-09-07 06:52:21 UTC
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..
Comment 5 kissall 2004-09-14 17:28:25 UTC
(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.
Comment 6 Jamesday 2004-09-14 18:07:26 UTC
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.

Comment 7 kissall 2004-09-14 19:19:35 UTC
 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.

Comment 8 Rowan Collins [IMSoP] 2004-09-25 17:36:30 UTC
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.
Comment 9 T. Gries 2004-11-11 23:30:41 UTC
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
Comment 10 Fantasy 2004-12-06 10:47:10 UTC
(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 :-)
Comment 11 Jamesday 2005-03-09 06:13:36 UTC
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).
Comment 12 T. Gries 2005-03-09 07:03:44 UTC
(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.
Comment 13 Christopher E. Granade 2005-03-09 08:58:40 UTC
(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.
Comment 14 T. Gries 2005-03-09 18:21:11 UTC
(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)
Comment 15 Omegatron 2005-03-21 21:16:15 UTC
(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.
Comment 16 Omegatron 2005-03-21 21:31:47 UTC
(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.
Comment 17 T. Gries 2005-03-22 00:23:09 UTC
> 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


Comment 18 Brian Jason Drake 2005-04-10 06:13:39 UTC
Why was this filed under "language setup"? Not all Wikimedia 
projects are simply differently language versions; they are 
different projects!
Comment 19 Brian Jason Drake 2005-04-17 04:17:12 UTC
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.
Comment 20 lɛʁi לערי ריינהארט 2005-06-17 20:31:10 UTC
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]]
Comment 21 lɛʁi לערי ריינהארט 2005-06-25 12:01:47 UTC
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]]
Comment 22 Niklas Laxström 2005-08-19 16:29:19 UTC
*** Bug 3200 has been marked as a duplicate of this bug. ***
Comment 23 SV Resolution 2005-08-24 06:29:54 UTC
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]]


Comment 24 Tobias Hahn 2005-10-10 12:10:45 UTC
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?
Comment 25 Rob Church 2005-10-10 13:53:31 UTC
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.
Comment 26 Christopher E. Granade 2005-10-10 19:51:06 UTC
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.
Comment 27 Edward Z. Yang 2005-10-11 00:16:27 UTC
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
Comment 28 Andre Engels 2005-10-11 07:56:21 UTC
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.
Comment 29 Rob Church 2005-12-25 23:19:43 UTC
(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.
Comment 30 Andre Engels 2005-12-26 00:25:11 UTC
> 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.
Comment 31 Edward Z. Yang 2005-12-26 00:49:15 UTC
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.
Comment 32 Edward Z. Yang 2005-12-26 00:53:34 UTC
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?
Comment 33 lɛʁi לערי ריינהארט 2005-12-26 08:57:06 UTC
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]]
Comment 34 Rob Church 2005-12-26 18:24:55 UTC
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.
Comment 35 lɛʁi לערי ריינהארט 2005-12-27 13:10:36 UTC
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.
Comment 36 Rob Church 2005-12-27 15:50:27 UTC
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.
Comment 37 Chris McKenna 2005-12-27 23:14:12 UTC
(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.
Comment 38 Rob Church 2005-12-27 23:21:49 UTC
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.
Comment 39 lɛʁi לערי ריינהארט 2005-12-27 23:58:44 UTC
(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)
Comment 40 Omegatron 2005-12-29 14:18:31 UTC
(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.
Comment 41 lɛʁi לערי ריינהארט 2006-02-01 20:31:16 UTC
*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 &lrm; b) append &rlm; c) unchanged (default).

best regards reinhardt [[user:gangleri]]
Comment 42 Rotem Liss 2006-11-25 10:17:13 UTC
*** Bug 8034 has been marked as a duplicate of this bug. ***
Comment 43 Connor Lee 2006-11-28 02:50:23 UTC
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 &lrm; b) append &rlm; c) unchanged (default).

Would this be that hard to do?
Comment 44 Connel MacKenzie 2007-02-13 17:26:56 UTC
Two cents: Every month that passes makes the "duplicates" problem worse.
Comment 45 Rob Church 2007-02-13 18:09:48 UTC
(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.
Comment 46 Brion Vibber 2007-03-12 16:23:31 UTC
*** Bug 9261 has been marked as a duplicate of this bug. ***
Comment 47 phi1ipp 2007-03-23 01:47:18 UTC
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.
Comment 48 Yonatan Horan 2007-03-23 02:35:26 UTC
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).
Comment 49 Anon Sricharoenchai 2007-04-17 11:00:49 UTC
http://bugzilla.wikimedia.org/show_bug.cgi?id=9604 <-- This would partially
resolve this #57 bug.
Comment 50 Casey Brown 2007-08-15 14:37:12 UTC
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! :-)
Comment 51 Danny B. 2007-08-16 00:45:56 UTC
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.
Comment 52 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-08-16 00:57:54 UTC
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
Comment 53 Anon Sricharoenchai 2007-08-16 04:22:53 UTC
``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.
Comment 54 Anon Sricharoenchai 2007-08-16 04:23:56 UTC
``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.
Comment 55 Anon Sricharoenchai 2007-08-16 04:26:16 UTC
``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.
Comment 56 Casey Brown 2007-08-16 13:23:54 UTC
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!
Comment 57 Anon Sricharoenchai 2007-08-16 13:43:15 UTC
(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)?
Comment 58 Casey Brown 2007-08-16 13:56:15 UTC
(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)
Comment 59 Anon Sricharoenchai 2007-08-16 14:10:51 UTC
> 
> 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?
Comment 60 Brion Vibber 2007-08-16 15:27:12 UTC
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/
Comment 61 AGK 2008-01-20 11:49:43 UTC
Pile-on support; a huge functionality.
Comment 62 Siebrand Mazeland 2008-04-07 08:26:17 UTC
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.
Comment 63 Anon Sricharoenchai 2008-04-08 07:45:03 UTC
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?
Comment 64 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-04-08 13:28:28 UTC
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).
Comment 65 Brion Vibber 2008-05-28 18:56:20 UTC
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!
Comment 66 Omegatron 2008-05-28 19:02:36 UTC
(In reply to comment #65)
> Now enabled for everybody (opt-in).

Woo!  Thanks everyone!

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links