This partly reverts Ied2e3f5. I haven't properly tested this before.
Rendering a bad extends (that extends a <ref> that's already extended)
not indented messes the order up and rips other extended <ref>s out of
context.
For now it might be better to stick to the previous, "magic" behavior:
Such an extends behaves like it is extending the *parent*, and is
ordered and indented as such. This is still not correct, but I feel
this is much better than rendering such a bad extends on the top level.
This patch also makes the code fail much earlier for a nested extends,
if this decision can be made already. In this case the error message is
rendered in the middle of the text (as other errors also are), not in
the <references> section.
Change-Id: I33c6a763cd6c11df09d10dfab73f955ed15e9d36
This partly reverts Id7a4036e64920acdeccb4dfcf6bef31d0e5657ab.
The message "cite_section_preview_references" says "Preview of references".
This line is not meant to be part of the content, but an interface message.
It should use the users (interface) language, not the content language.
Change-Id: I1b1b5106266606eb0dfaa31f4abd3cee9ba92e8c
These edge cases are handled correctly already, I just forgot to
remove the TODOs when updating test content.
Note that there's only one TODO left, and it's to forbid a feature which
actually works!
Change-Id: I0d3a1f55f0ce943b0d034dda40e3779fbf241fe4
Same as Ib6e9de6.
We must reset the build-in "list-item" counter to make this code behave
sane in Firefox. It looks like this is even described in the CSS spec
and it is not Firefox having a bug, but Chrome being "clever" and not
following the spec.
Bug: T229307
Change-Id: I955786e2b68d087c819a962ded3c571946c61f78
All mock screenshots on
https://de.wikipedia.org/wiki/Wikipedia:Technische_W%C3%BCnsche/Topw%C3%BCnsche/Erweiterung_der_Einzelnachweise
show this extra dot.
Note the numbering scheme "1." and "1.1" (without the dot) was not a
mistake. It's not uncommon to only have the extra dot on the first
level.
However, I feel the scheme "1." and "1.1." might be a little more
consistent and less surprising.
Change-Id: I0dc467755926f82d88a48fb7594af0bde8bbee21
This simplifies as well as fixes a series of issues with this regular
expression:
* Before, the wikitext `<REF><REF>` would not trigger the error, but
`<ref><ref>` would. Parser tags are case-insensitive, but the error
check was not.
* Before, the wikitext `<ref><ref name="<">` would not trigger the error.
That's a valid name. The error check should not stop just because it
found a `<`.
* Both the old and the new code do *not* fail with the wikitext
`<ref><ref</ref>` where the inner `<ref` does not have a closing `>`. I
was thinking about changing this, but figured it might be used as a
feature.
* The old code was not able to properly understand HTML comments,
<nowiki> tags and such that contain a line break. That caused
inconsistent and confusing error reporting in some cases, but not in
others. This change *reduces* the amount of errors this code produces.
* The old code was looking for "SGML tags" with names that could be
anything, not just alphanumeric characters. This allowed for strange
edge-cases like `<ref><>><ref></>></ref>` that have not been reported,
but should be. This change *increases* the amount of errors. However,
relevant edge-cases should be extremely rare.
Note the ++ avoids backtracking, speeding up the regex.
Change-Id: I0c61a245f4f743871b4cad886ce239650af2b37c
Naming the tag is consistent with other extensions. Going into detail
about specific attributes or closing the XML tag is unnecessary.
Change-Id: I0c81707222fcf18d12a313d4d3973bf77848eddd
We never access Language directly, so proxy its method instead of
returning the full object.
I believe I've found a bug, but not fixing here: the footnote body
numeric backlinks like "2.1" behave as if they were decimals rather
than two numbers stuck together with a dot. So they are localized
to "2,1".
Bug: T239725
Change-Id: If386bf96d48cb95c0a287a02bedfe984941efe30
This is a mess of a function, and the tests show it. There are lots
of side-effects and context-sensitivity, which can be addressed in
later work. The interface with ReferenceStack is too wide.
Change-Id: I00cab2a555b2a9efd32d937979cd722d43ac1005
I was able to track this code down to I093d85d from 2012, which was done
right after the ParserAfterParse hook was introduced. I believe the
redundant code path was left to keep the Cite extension compatible with
old MediaWiki versions that did not had this hook yet.
I also noticed this code path is most probably entirely redundant with
the current version of MediaWiki. The *only* thing this code does is
blocking the ParserBeforeTidy hook from doing the same thing a second
time if the ParserAfterParse hook was called before. But it does *not*
block any other compination, e.g. if the two hooks are called the other
way around, or the same hook twice.
In core, it looks like it is impossible for the ParserBeforeTidy hook
being fired without the ParserAfterParse hook being fired before. If this
is true, this is in fact dead code.
Change-Id: Iacf8b600c7abdeaf89c22c2fc31e646f57245e47
Encapsulate the language interfaces, this will be used to replace
global wfMessage calls in future patches.
Change-Id: I7857f3e5154626e0b29977610b81103d91615f65
This patch applies a few closely related changes:
1. Instead of reusing and possibly messing with the existing
"mw-ref-linkback" counter, I start a new one.
2. I also gave both new counters better names, following the
"mw-ref-…" naming scheme.
3. We must reset the build-in "list-item" counter to make this code
behave sane in Firefox. It looks like this is even described in the
CSS spec and it is not Firefox having a bug, but Chrome being "clever"
and not following the spec.
Bug: T239787
Change-Id: Ib6e9de689129b7c2d50e3a1c720c0d2d5a0c0986
This makes it obvious that our function isn't sensitive to the input value.
Also rearranges a string concatenation to make the element wrapping clearer.
I probably should have switched to the HTML class here, but I'm not sure what
the advantages would be.
Change-Id: Ife3424ce68588f73f168b10e63e6cd81c4a60084
