Last modified: 2014-09-24 01:33:05 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)
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.
*** Bug 33738 has been marked as a duplicate of this bug. ***
Looks fixed.
No it's not fixed. Can someone please ban duplicatebug@googlemail.com ? Adding nonesense and confusing account name
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.
duplicate to bug 10863?
(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 ***
