Page MenuHomePhabricator

File history from shared repository parsed in context of local wiki
Closed, ResolvedPublic

Description

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)


Version: 1.16.x
Severity: minor

Details

Reference
bz22001

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:50 PM
bzimport set Reference to bz22001.
bzimport added a subscriber: Unknown Object (MLST).

Bryan.TongMinh wrote:

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.

Bryan.TongMinh wrote:

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

No it's not fixed. Can someone please ban duplicatebug@googlemail.com ? Adding nonesense and confusing account name

sumanah wrote:

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.

I'm happy to hear that he's not a troll, just someone with a confusing user name looking with his nose......

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).

(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.

(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 ***
Gilles raised the priority of this task from Low to Unbreak Now!.Dec 4 2014, 10:12 AM
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to Low.Dec 4 2014, 11:21 AM