| • bzimport | |
| Apr 1 2009, 2:41 AM |
| F5556: bug18295.patch | |
| Nov 21 2014, 10:32 PM |
Author: smile
Description:
<s toclevel="1" level="2" line="UNIQ28cf615b3f10792f-nowiki-0000000B-QINU" number="39" />
where section-title-text behind the UNIQ key is lost:
Version: 1.15.x
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=25417
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T28213 Strip marker (UNIQ / QINU) issues (tracking) | |||
| Resolved | None | T20295 Strip markers exposed in anchor links with ==[[Link|<nowiki>text</nowiki>]]== |
herd wrote:
UNIQ strings are not a feature, they are a consequence of malformed parsing (basically a big flashing sign that says "BAD WIKICODE HERE". In this case it seems no valid anchor string can be formed from [[Link|<nowiki>text</nowiki>]]. Changing topic appropriately. This might be a dupe or WONTFIX though.
smile wrote:
(In reply to comment #1) OK, thanks. What puzzles me is, why do UNIQ strings have to change at all and/or so frequently? And even when a wiki-page doesn't change? That's a real drag in archived talk-pages, where "nowiki" is used quite frequently in section-titles.
Proposed fix: Swap the order of tag and link unstripping in Parser::formatHeadings()
Easy fix: Swap the order of link unstripping and extension tag unstripping in Parser::formatHeadings().
It is IMHO far more likely that a link contains an extension tag (like above), while offhand I can't think of a case, where an extension tag would contain an half-parsed link at that stage of parsing.
(In reply to comment #2)
(In reply to comment #1) OK, thanks. What puzzles me is, why do UNIQ strings
have to change at all and/or so frequently? And even when a wiki-page doesn't
change? That's a real drag in archived talk-pages, where "nowiki" is used quite
frequently in section-titles.
The whole point of UNIQ keys is that they are not predictable, so you can't break parsing by inserting some of them to a page.
Attached:
(In reply to comment #3)
Created attachment 5983 [details]
Proposed fix: Swap the order of tag and link unstripping in
Parser::formatHeadings()
Paul, could you apply the patch now that you have commit privs?
Attached:
(In reply to comment #6)
Looks like this is already fixed from my testing on wikipedia.
It's not. Try putting
in a page and look for <span class="mw-headline" id=".7FUNIQ...QINU.7F">.
However, I don't think this can be fixed at the moment, as Brion points out at bug 93 comment 30 that the parser is currently being frozen and rewritten.
(In reply to comment #7)
However, I don't think this can be fixed at the moment, as Brion points out at
bug 93 comment 30 that the parser is currently being frozen and rewritten.
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/54555