Same as Icfa8215 where we removed the …_suffix messages.
This patch is not blocked on anything according to CodeSearch:
https://codesearch.wmcloud.org/search/?q=cite_references%3F_link_prefix
According to GlobalSearch there are 2 usages we need to talk about:
https://global-search.toolforge.org/?q=.®ex=1&namespaces=8&title=Cite.references%3F.link.prefix.*
zh.wiktionary replaces "cite_ref-" with "_ref-", and "cite_note-"
with "_note-", i.e. they did nothing but remove the word "cite". This
happened in 2006, with no explanation.
ka.wikibooks and ka.wikiquote replace "cite_note-" with "_შენიშვნა-",
which translates back to "_note-". One user did this in 2007,
16 seconds apart.
It appears like both are attempts to localize what can be localized,
no matter if it's really necessary or not.
https://zh.wiktionary.org/wiki/Special:Contributions/Shibo77?offset=20060510https://ka.wikiquote.org/wiki/Special:Contributions/Trulala?offset=20070219
Note how one user experimented with an "a" in some of the edits to
see what effect the change might have, to imediatelly revert it.
The modifications don't really have an effect on anything, except on
the anchors in the resulting <a href="#_ref-5"> and <sup id="_ref-5">
HTML. It might also be briefly visible in the browser's address bar
when such a link is clicked. We can only assume the two users did this
to make the URL appear shorter (?). A discussion apparently never
happened. Bot users are inactive.
Both pieces of HTML are generated in the Cite code. Removing the
messages will change all places the same time. All links will
continue to work. The only possible effect is that hard-coded
weblinks to an individual reference will link to the top of the
article instead. But:
a) This is extremely unlikely to happen. There is no reason to link
to a reference from outside of the article.
b) Such links are not guaranteed to work anyway as they can break
for a multitude of other reasons, e.g. the <ref> being renamed,
removed, or replaced.
c) Even if such a link breaks, it still links to the correct article.
There is also no on-wiki code on zh.wiktionary that would do anything
with the shortened prefix:
https://zh.wiktionary.org/w/index.php?search=insource%3A%2F_%28ref%7Cnote%29-%2F&title=Special%3A%E6%90%9C%E7%B4%A2&profile=advanced&fulltext=1&ns2=1&ns4=1&ns8=1&ns10=1&ns12=1&ns828=1&ns2300=1
I argue this is safe to remove, even without contacting the mentioned
communities first.
Bug: T321217
Change-Id: I160a119710dc35679dbdc2f39ddf453dbd5a5dfa
This classifies as a "warning" because we still show everything,
just with an error message appended.
Disabling the Parsoid tests right away hopefully makes it easier to
do the same change in Parsoid.
Bug: T202593
Depends-On: If14acd1070617ca8c4d15be6b1759bd47ead4926
Change-Id: I294b59f989f553932b40d08308906dd72d92d2cd
This error message really always meant nothing but "there is an
unknown parameter in your <ref> tag". It's unnecessarily confusing
only for historical reasons. See T299280#9384546 for a long
explanation.
Bug: T299280
Change-Id: Ic224d5828f7b7ac0928c44f526c61654ccf3425e
This reverts a very tiny part of Ib3fdc89 from 2 weeks ago. The
reasons are explained in Ib3fdc89. Short version:
* The ->parse() calls have drastic performance implications.
* Allowing wikitext and HTML in this message also makes T321217
worse.
The new message "cite_reference_backlink_symbol" is kept and still
used in the UI. Just not in these two messages any more. This is a
minor redundancy we want to get rid of at some point. But it's not
critical for the moment. This will be done as part of T321217.
Nothing will break on the wikis. Some wikis have customizations for
"cite_references_link_one" and "cite_references_link_many" in place.
This will continue to work as before Ib3fdc89.
Bug: T339973
Change-Id: I933771e3ad67cd530bcf5ee8469cef35ea1070d2
The WikiEditor extension has a button and some help text that
is only applicable if the Cite extension is enabled. Move
that (with some modifications) to the Cite extension instead.
Bug: T339973
Depends-On: I8256660f9c6886d6764b45735284e00308fc56e5
Change-Id: Ib3fdc897dd3330f69c5832003d4c3cb1e6dba2f3
Perform the validation in validateRef, and display a new error message for
broken "follow" refs. This changes existing behavior, where broken folow
ref content is arbitrarily displayed at the top of the references list and
no error is rendered.
Thanks to weasely wording, the new error can later be reused for "extends"
errors.
Bug: T240858
Change-Id: I506e4dcd1151671f5302ecd99581145d979d8124
These create bogus output, depending on the surrounding wikitext the
<ref> tag is used in. For example, this example wikitext:
* Example.<ref name="1">a</ref> More text.
… will be rendered with the "More text" sentence wrapped on the next
line, outside of the list. However, this does *not* happen in many of
the localizations, e.g. German, because many Tanslatewiki translators
did not copied the bogus \n. Why should they.
TL;DR: These newline characters either do nothing, or destroy the output.
In both cases the proper fix is to replace them with spaces.
Some of the test cases touched in this patch demonstrate the issue.
Change-Id: I395a40637a5293eda1f477963d252ce1a215f8b2
This resolves another TODO. Since this is an intentional limitation in
the design of the feature, I find it pretty signigicant to give it it's
own error message.
Note that the text does not need to be perfect, just good enough for now.
We will review all error messages later via T238188.
Bug: T242141
Change-Id: Id9c863061e855350320131e81f6702c8810736f4
It's possible to nest <references> by using tricky constructs like the
{{#tag function, and this breaks our rollback logic. Try to show normal
output, otherwise show an error.
Includes regression tests.
Bug: T242437
Change-Id: I33e497cdf8508ce7ccb7f0f315c00af5eee47d0e
In historical versions of the Cite extension, unclosed <ref> tags were
sometimes caught and rendered as another, unrelated validation error.
This is no longer the case thanks to a more accurate check for
unclosed <ref> tags.
Remove user-facing text explaining the edge condition.
Change-Id: Ic27e120213e39e3774ad7c8ee76eabd2faa74234
Naming the tag is consistent with other extensions. Going into detail
about specific attributes or closing the XML tag is unnecessary.
Change-Id: I0c81707222fcf18d12a313d4d3973bf77848eddd
… and make the error message for bad dir="…" shorter and more to the
point.
Now I understand why the error reporting was not done when $text was
empty: the error was actually appended to $text, which messes with
everything else that also works with the $text variable! This even
includes the API. This error message was exposed via the API. That was
certainly a bug.
With this patch, all error checking for the dir="…" attribute is now
done way down, when rendering the <references> section.
Note this also fixes a bug where the dir="…" was *not* rendered when
previewing a section.
Change-Id: I4ab0cb510973ed879c606bfaa394aacc91129854
This changes the a11y support on the main backlinks by introducing the usage
of title and aria-labels. The support for these elements increased a lot since
the topic was first tackled and seems the appropriate way to go.
A new message was introduced for the link that will be set when directly
coming from a clicked refrence to emphasize that the can jump back to where
he came from.
Bug: T206323
Change-Id: Ifa56d41bcdb8100e19f29619796b62bb3c886d2f
Adding option for dir attribute in ref tags. The value must be a valid
direction ('ltr' or 'rtl', case insensitive) or the direction will be
stripped out.
The directionality of the li element is set using a css class accordingly.
Bug: T15673
Change-Id: Iff480bc8cc4f81403b310e8efecd43e29d1d4449
This is based on the popular 'count' parameter from Template:Reflist on
English Wikipedia, which has also been adopted by many other wikis.
That template's 'count' parameter allows maximum flexibility on a per-
page basis. This was important because the template can't know how many
references the list will contain. Users typically manually add (and
later, increment) the 'count' parameter when the list exceeds a certain
threshold.
The template currently sets an exact column count (via the CSS3
property `column-count`).
This patch improves on that by instead using the closely related CSS3
`column-width` property. This automatically derives the column count
based on the available space in the browser window. It will thus create
two or three columns on a typical desktop screen, and two or no columns
on a mobile device.
The specified width is the minimum width of a column. This ensures that
the list is not split when rendered on a narrow screen or mobile device.
It also hooks into the raw list before parsing and adds the class only
when the list will contain more than a certain number of items. This
prevents very short lists from being split into multiple columns.
Templates like Template:Reflist on English Wikipedia currently are not
able to set inline styles on the list element directly, which is why
they set it on a `<div>` wrapping the `<references />` output. Because
of this, the feature of the Cite extension must not be enabled at the
same time, as that would result in both the template's wrapper and the
references list being split. The end result would involve sitations with
three columns split in four sub-columns, creating a complicated mess of
nine intermixed columns.
To provide a smooth migration for wikis, this feature can be disabled by
default using `$wgCiteResponsiveReferences = false`. Each individual
template createing reference list can then be migrated, by removing the
wrapper column styles and instead settting the new "responsive"
attribute, like so: `<references responsive />`.
Once any conflicting templates have been migrated, the default for the
wiki can be swapped by setting `$wgCiteResponsiveReferences = true`.
If wikis wish for some templates to keep their custom column splitting
behaviour, templates can also opt-out by setting `responsive="0"`, which
will make sure that it will keep behaving the current way even after the
feature becomes enabled by default for the wiki.
In summary, when disabled by default, pages can opt into this system
with `<references responsive />`. When enabled by default, pages can opt
out of the system with `<references responsive=0 />`.
* Deprecate cite_references_prefix/cite_references_suffix.
This message is rarely used and opens up compatibility hazards.
It was already removed by Parsoid, but the PHP implementation
still had it. It's typically used to add inline styles to the
wrapper which is more appropiately done in Common.css (or
obsoleted as part of the skin or Cite extenion itself nowadays
depending on what style in question).
It was also a HTML-style message with separated open and close
segments, which is an anti-pattern in itself.
* Declare module target explicitly and include mobile. The absence of
this stylesheet caused subtle BiDi/RTL bugs on mobile.
Bug: T33597
Change-Id: Ia535f9b722e825e71e792b36356febc3bd444387
In reference links, brackets are wrapped in nowiki tags to avoid
breaking the link. This uses instead [ and ] (ASCII for
[ and ]). This simplifies parsing and mitigates the issue of
strip markers in references data.
Bug: T127787
Change-Id: Ibacae55eb99233d89d5c68261e3259cb2b723451
* The query request prop=references will return a JSON blob of all
references in the page
* Conveniently references are returned with an array id key that corresponds
to an anchor tag in the HTML
* When references storage is disabled the API request will trigger an
error.
Bug: T123290
Change-Id: I81a965bcb47d17df18f1e415e3c25f88f6b48ffc
Clarified error message by changing it to "The opening <ref> tag is malformed or has a bad name".
Bug: T115810
Change-Id: I0c9cb8f5e81ebdb194c57f24a5792b682dd290dc
This is to make it apparent that this isn't part of the preview
of the section itself. A span class is also added.
Bug: T125981
Change-Id: I62c8dca8ee42e79c6b7cd7f837f4e7ee65f77770
For a section preview with missing <references/> tag,
add reference lists for each group.
Bug: T7984
Change-Id: I2ca1b62fc068b20b7df4b0af2e3e79535e656259
