Last modified: 2014-11-18 18:07:19 UTC
If a user from another wiki has had some of their edits imported, anyone who creates that account will have those edits attributed to them (possibly this will be incorrect!) Ghost accounts (with imported edits, but which have never been created) should not be permitted to be created unless the user has a global account which includes all wikis where the imported edits came from. So if User:A@enwikibooks consists of edits imported from User:A@enwiki and User:A@meta, then it should be joined to User:A@global if they "own" (as defined by SUL) the accounts at enwiki and meta. If not, then some bureaucrat/SUL admin/steward/whatever intervention should be able to override this, and force the account to be merged (as appropriate). Until then (SUL merge time for the involved accounts) the account User:A@enwikibooks should not be possible to create, as this makes it possible for edits to be incorrectly attributed. Again, it'd be ideal if this could be overridden by bureaucrats/SUL admin/steward/whatever.
*** Bug 18163 has been marked as a duplicate of this bug. ***
Could we at least have a reason why this is INVALID?
I think it's a separate issue to SUL. SUL is another level of complication, which would be nice to address, but to solve the basic problem, edits should just be attributed to the user at the exporter-wiki instead of the local importer-wiki.
When importing a page, the user attribution should just point to the originating wiki. Read Brianna's blog entry at http://brianna.modernthings.org/article/193/edits-in-unexpected-places ;-) The same happened to me on Wiktionary, where I first wondered where the h*** some edits of mine came from, and why. Make an import process even more transparent and traceable (as well as correct) by just adding :en: (etc.) to 'imported' userlinks!
Raising severity to (at least) 'major', as this can be a severe GFDL issue! Added 'easy' tag, as this actually should just/mainly be a simple XML output issue (adding a ":project:lang:").
Removing easy, because it's not that easy :) Adding a project:lang: to the export format wouldn't make sense for the vast majority of wiki installs out there; nor can we assume that a given interwiki prefix is defined on the target wiki.
(In reply to comment #6) > Adding a project:lang: to the export format wouldn't make sense for the vast > majority of wiki installs out there; nor can we assume that a given interwiki > prefix is defined on the target wiki. > @wiki prefix: Oh, of course; you can export on any wiki and import on any wiki; I forgot that ;-) Just had our cool automatic on-the-fly importing tool in mind. So, when interwiki prefixes aren't suitable, why not just adding the URL of the wiki in front of the user (making an external link)? <username>Foobar</username> => <username>http://foo.bar/User:Foobar</username> Or *if* this should break anything (backwards compatibility) maybe use the <base> tag as input information: <base>http://en.wikipedia.org/wiki/Main_Page</base> By the way, <base> should not point to the (movable) main page, instead just use <base>http://en.wikipedia.org/</base> Isn't it possible to make an external link (http) within a recentchanges table, revision table etc.?
Here's an example http://scratchpad.wikia.com/index.php?title=User:Simetrical&action=history (a mockup - not a working feature) The advantage of using @ is that it's a banned character in usernames (at least within Wikimedia projects) so someone else can not make that account and claim such edits as their own.
*** This bug has been marked as a duplicate of bug 7240 ***
