Last modified: 2014-09-24 01:33:05 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 22001 - File history from shared repository parsed in context of local wiki
File history from shared repository parsed in context of local wiki
Status: RESOLVED DUPLICATE of bug 10863
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.16.x
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
: crosswiki
Depends on: 11
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-03 14:00 UTC by Maarten Dammers
Modified: 2014-09-24 01:33 UTC (History)
10 users (show)

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


Attachments

Description Maarten Dammers 2010-01-03 14:00:01 UTC
When viewing a file at a local wiki (nl.wikipedia.org in this case) from a shared repository (commons.wikimedia.org in this case), the file history section is parsed as being on the local wiki. Any links in the file history which should point to the shared repository now points to the local wiki.

See for example http://nl.wikipedia.org/wiki/File:Haarlem_Hoofdwacht1.JPG
In the text ''Ludvig14'' points to http://commons.wikimedia.org/wiki/User:Ludvig14 , but in the file history it points to http://nl.wikipedia.org/w/index.php?title=Gebruiker:Ludvig14

The current version of nlwp is 1.16alpha-wmf (r59858)
Comment 1 Bryan Tong Minh 2010-10-23 15:10:57 UTC
There is no trivial way doing so in the current system. I think the easiest way is to query the API for the whole file description parsing.
Comment 2 Bryan Tong Minh 2012-01-15 13:46:58 UTC
*** Bug 33738 has been marked as a duplicate of this bug. ***
Comment 3 db [inactive,noenotif] 2012-09-29 19:22:34 UTC
Looks fixed.
Comment 4 Maarten Dammers 2012-09-29 21:32:55 UTC
No it's not fixed. Can someone please ban duplicatebug@googlemail.com ? Adding nonesense and confusing account name
Comment 5 Sumana Harihareswara 2012-09-29 21:43:37 UTC
We should not ban duplicatebug, but yes, that's a confusing account name.

Thanks for checking on the reproducibility, duplicatebug, but it looks like you were not quite diligent enough there. :)

Also cc'ing another developer to ask whether they can take a look at the bug.
Comment 6 Maarten Dammers 2012-09-29 21:45:32 UTC
I'm happy to hear that he's not a troll, just someone with a confusing user name looking with his nose......
Comment 7 Brad Jorsch 2012-10-01 03:21:58 UTC
Certainly not fixed.

(In reply to comment #1)
> There is no trivial way doing so in the current system.

This, at least for Wikimedia wikis. 

> I think the easiest way
> is to query the API for the whole file description parsing.

For ForeignAPIFile, that would work. In fact, support is already there now, just use 'parsedcomment' rather than 'comment' in the API prop=imageinfo call. Although it looks like parsedcomment needs to somehow be convinced to return full rather than relative urls.

For ForeignDBFile, it doesn't look like it would be that easy. Right now it just reads the comment directly from the database and parses it with the local parser. We'd need to *add* API calls, or some equivalent to the action=render call used to get the description page text. Not sure how expensive either of those options might turn out to be; the least expensive option might be to somehow roll the action=render and the history-comment-render into one call (be it api or action=foo).
Comment 8 db [inactive,noenotif] 2012-10-01 19:21:42 UTC
(In reply to comment #4)
> No it's not fixed. Can someone please ban duplicatebug@googlemail.com ? Adding
> nonesense and confusing account name

Sorry for confusing. I have only looked at the description page and the user in the table, this was linking to commons and not linking. Sorry, I have not seen the link in the upload comment and that this was the problem.

Another way is to strip wikilinks before parsing the upload comment, so this part is unlinked like the uploader name.
Comment 9 db [inactive,noenotif] 2012-10-27 14:56:29 UTC
duplicate to bug 10863?
Comment 10 Brad Jorsch 2012-10-28 15:09:44 UTC
(In reply to comment #9)
> duplicate to bug 10863?

Looks like it to me.

*** This bug has been marked as a duplicate of bug 10863 ***

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


Navigation
Links