It can happen that an error is reported multiple times for a given
reference. In this case, we only display one.
We still display different errors if a reference contains multiple
different errors. This behaviour is differs from the legacy parser's
(so, in this case, we add the category
cite-tracking-category-cite-diffing-error), but not from the legacy
parser's desired behaviour, as hinted by the various comments and TODO
in this area.
Bug: T380153
Change-Id: I9b3d5cbd086fc72c66a2afbae8f92297681989ce
The type hints added in I3e0df790ff9db2fa630f82408a7254a359fe61ca
were sufficient to allow phan to detect that we were possibly passing
a null value in one instance. The other instance was a false positive.
Follows-Up: I3e0df790ff9db2fa630f82408a7254a359fe61ca
Change-Id: I3bacc2aff3d36719133554a8f70d50a3790b84e4
There is only one child, so first/last element child are the same, but
it's a little less confusing to use 'first' here.
Follows-Up: Ifeb3b216e898bec1c3eb5917262820c5809fda45
Depends-On: I753bbbfaf99fb486384b0fa97de71159abb504b3
Change-Id: I65873c117cbd3e1d6efd82797c7b49bf707f5c3a
This doesn't change behavior yet, it's pure wiring to make the
attribute available to Parsoid logic.
Bug: T378567
Change-Id: I6182b601f6fee66a9c32d5006d0a36150eb47e7f
After this patch, Parsoid-rendered pages will include the same
footnote markers as the legacy parser for custom group markers.
The divergent CSS implementation is left intact, for a soft migration.
Bug: T377454
Change-Id: I576dfff4155fb8c2f91ef0d28a65b319aa5bbb07
Behavior change: previously, an error would be rendered once the
custom markers run out. After this patch there is a graceful fallback
to default group rendering (eg. "lower-greek 1000").
This is a slight improvement, but is user-facing so should be
discussed before merging.
In future work we'll render custom marks programmatically so this edge
case would be unreachable, and since the error message only exists to
nudge editors to extend the custom group symbol sequence, this would
also become wasted effort.
This patch splits out a lower-level method which produces the bare
mark label, with no link or wikitext formatting. The patch narrows
and simplifies the interface so that the method can be made available
to Parsoid, and will be converted to a service in a separate patch.
Bug: T377454
Change-Id: I719b60b46cdef0be7463d76e9125d75ab4f333ae
Check the array part first and afterwards the property for null,
which does not need the isset() error suppression.
Found by a new phan plugin (2efea9f989)
This bypass a false positive from phan (T378284)
Change-Id: I08651c4b2cd03ecfb38d28ca1cbff599d922208a
isset() should only be used to suppress errors, not for null check.
When the variable is always defined, there is no need to use isset.
Found by a new phan plugin (2efea9f989)
https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#isset
Change-Id: I2eee98fdcb21192108183c431b10e0072b951f72
Implicitly marking parameter $... as nullable is deprecated in PHP
8.4. The explicit nullable type must be used instead.
Bug: T376276
Change-Id: I73a4ce1ecd9b4fe040e5bfd22889e783071fab0d
This avoids the use of Parsoid's SiteConfig::getMWConfigValue() method,
which is unnecessary when the extension has direct access to MediaWiki
services itself.
This also fixes the omission of CiteResponsiveReferencesThreshold from
the extension.json.
Change-Id: I01b43136b0827f185523f1318253372b09750de4
This seems to play well with Popups with and without
Ie8fa1672b9fd . However, it's not clear to me why this still works
and even gives priority to the Popups implementation when present,
regardless of the order the extensions are loaded in. Happily, this
is the desired behavior.
Bug: T363162
Change-Id: Ic479c0a381ee16d1abcecfdd5ee48f0afccc1d3f
This has no user-facing consequences. The constant can be renamed any
time again, if needed. It's not used anywhere else:
https://codesearch.wmcloud.org/search/?q=BOOK_REF_ATTRIBUTE
Bug: T373307
Change-Id: Ia4d588e926bb6e75f96048f2d3782c0f23ece514
The Parsoid error messages are missing a couple of parameters, according
to the json i18n files; this patch fixes that issue.
Change-Id: I4232c0b71ecc6d6f1220db3988e67d9cd4eb3d58
This moves existing code around a little bit without changing
anything, as proven by the tests.
This is motivated by Iaca0e14.
Change-Id: I30366d32b07f87f238b045f0d7817686b5cc26bd
It's always a string anyway. Also improve the test coverage. The
localization was pretty much untested before.
Change-Id: Ie6f34c67ae7dd9559346eb45a2604e14c5633991
The message cite_references_link_many_format_backlink_labels contains
e.g. "a b c …" and so on, to be used as alternative backlink labels
when a single reference is re-used multiple times. The default numeric
rendering is "1.1 1.2 …" and so on.
The two labels end in the message cite_references_link_many_format as
parameters $2 and $3. But only one of the two parameters is ever used.
By default the alternative label in $3 is unused.
This implies that everything about these alternative backlink labels
including the error message is effectively dead code most of the time,
never to be seen on the majority of wikis.
This change makes it possible to disable the message without breaking
anything. Instead the code will silently fallback to the default
behavior of showing the numeric label. This is much more efficient
than rendering possibly hundreds of error messages that never show
up anyhere. The same optimization is already done for the extremely
similar cite_link_label_group-… messages, see
FootnoteMarkFormatter::fetchCustomizedLinkLabel.
This is also partly motivated by T335129 as well as T321217.
Change-Id: Iab818d7db7eddaf7091234f6a22a18cdff70f8e8
This is a direct follow up for I6f05842 where we already started
supporting dashes, but converted them to underscores. The only change
in this patch is that the CSS class will use the message key as it
is, without the dashes being converted to underscores. I added a test
case specifically for this.
Bug: T352676
Change-Id: Ic22e897c27b8371e3b1ed63932b619e7af71bd5c
Final step to get the i18n key names align with this extension.
Note that the few community overrides should have a copy of the
keys we're changing here in place so the overrides work for both
variants as long as the deployment is not finished.
Bug: T363156
Change-Id: Idf098d2cb04e8f02247b78e6b4866338eaf02b44
We have a use case in which the client needs to be able to use
language utilities in the content language (footnote markers), so the
data must be wired through. This will only be done in VE, and in the
special case that the interface language != the content language.
Bug: T369613
Change-Id: I2c10e1e36ba594da98e0efa433dd9e1a25aae6fe
This is motivated by T367749 where we probably need this code to be
separated. This minor refactoring just moves existing code around
without changing anything. The idea is just to make the concepts more
visible in the code.
Bug: T367749
Change-Id: I765d19fa9cb43a6f8492b707a7ae46ddffe43897
We want it to be possible to turn a <ref> into an extended one after
it was re-used for the first time, not knowing if it later turns out
to be an extended ref.
This should work: <ref name=x/> is a short re-use of a ref that later
turns out to be a <ref extends=… name=x>…</ref>.
<ref name=x></ref> is just another syntax that should behave
identical.
However, it should probably not be possible to turn
<ref name=x>foo</ref> into a subref later because it really, really
looks like a normal ref. Even if the content matches with a later
<ref extends=… name=x>foo</ref> and we usually ignore identical
content, I suggest to block this with a dedicated error message. But
this is for a later patch. This patch here just documents the status
quo.
This patch also contains minor code cleanups that will be useful in
Ia752a7d.
Bug: T367749
Change-Id: Ie38769b36e5c476b96e7af7f03b0fc800b32ba97
The idea is to make the code less ambiguous and easier to predict.
We passed the same information around two times in a few places.
Change-Id: I39c7a2962bb70bbe40074986e63b1051d0766ea2
