ayg wrote:

*** Bug 8952 has been marked as a duplicate of this bug. ***

Why is this an invalid bug report? User names of imported pages may be completely different from those in the local wiki, so e.g. links to user pages are misleading.

happy.melon.wiki wrote:

No idea; it's a perfectly legitimate problem, whether or not the solution is to make them interwiki links.

Raised importance because of copyright problems, but reduced priority because there are workarounds and such imports are mostly improper in the first place.
See also a recent discussion at https://meta.wikimedia.org/w/index.php?title=Meta:Babel&oldid=3070173#importing_edits_and_then_refusing_to_attribute_them_properly

Anyway, if we ever decided to take care of this, I think that the technical solution would be to show imported edits in a different way in the history and to hide them from Special:Contributions. This shouldn't be too difficult but could be expensive for the database, I guess.

• Bug 13798 has been marked as a duplicate of this bug. ***

James says on this bug that it «will become irrelevant when SUL finalisation is complete (for WMF public wikis) anyway».
https://meta.wikimedia.org/w/index.php?title=Talk:Single_User_Login_finalisation_announcement&diff=prev&oldid=5464146

Of course this is true only of one specific possible implementation of what requested here, which is only a part of bug 18209, and only for transwiki import between Wikimedia projects, but not for importupload. So this bug will always be a valid request, be it acceptable or not.

Angela suggested this solution (with importupload and XML editing as workaround) in the discussion that probably cause bug 8952 to be filed. See http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/36825/focus=36828 where this problem is mentioned as reason to avoid transwiki import from arbitrary sources.

• Bug 24686 has been marked as a duplicate of this bug. ***

• Bug 54990 has been marked as a duplicate of this bug. ***

This is only about the display in the interface; the database and the web API do not misattribute any imported edits, because they are assigned to no user ID (rev_user = 0).

Sometimes there were bugs in the import itself though, with rev_user > 0. In such a case, it seems T29629 is the only option for T20209, unless the database can be cleaned up.

Came here from my bug T111605 after @Legoktm mentioned it. Worth reposting a comment from there here:

In T111605#1633446, @Nemo_bis wrote:

MariaDB [wikimania2016wiki_p]> select rev_user_text, rev_user from revision join page on rev_page = page_id and page_title = 'Done' and rev_user_text = 'Scott';
+---------------+----------+
| rev_user_text | rev_user |
+---------------+----------+
| Scott         |        0 |
| Scott         |        0 |
| Scott         |        0 |
+---------------+----------+
3 rows in set (0.02 sec)

Special:Contributions recently stopped showing such contributions, but that's an unintended consequence of @aaron's 99984c809 which should probably reverted.

Note: SUL finalization has removed the "local users" referred to in the original bug report from 2006. However as far as I'm aware the import tool is still setting rev_user = 0 (T111605). Once that's been dealt with, the possibility is there for a cleanup script to be developed to fix attribution on all imported edits.

Change 386625 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/core@master] Avoid DB rows with usable names but ID = 0 by introducing "interwiki" usernames

https://gerrit.wikimedia.org/r/386625

Change 386626 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/extensions/CentralAuth@master] Update for core interwiki user handling change

https://gerrit.wikimedia.org/r/386626

Change 386626 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@master] Update for core interwiki user handling change

https://gerrit.wikimedia.org/r/386626

Change 386625 merged by jenkins-bot:
[mediawiki/core@master] Avoid DB rows with usable names but ID = 0 by introducing "interwiki" usernames

https://gerrit.wikimedia.org/r/386625

I think it may be related to T36873