* Include the README in generated JS docs.
* Tweak stray top-level files to explain their role. Note that the
wmf template forces these files to appear on the docs home page...
Bug: T358641
Change-Id: If421414340903991f50a06a76551bd7cd2904c5e
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
There are multiple formats for these IDs:
cite_ref-1, cite_ref-2, and so on for anonymous <ref>s without a name.
cite_ref-name_1-0 for named references, where "name" is the custom name,
and "_1" is the sequential number for the reference (same number as above).
The final "-0" is counting the usages. If a named <ref> is only used once,
there is no cite_ref-name_1-1 anywhere on the page.
The later was already checked by the code. But we forgot about unnamed
references! As a consequence IDs like the cite_ref-1 above got misdetected
as reused references.
This patch tries hard to extract code into named functions, so it becomes
much more clear what they do, and why.
Bug: T215317
Change-Id: Iedb5b0c3dffae19bad7df9a43ed2d4512b3921ec
As far as I can tell the effect of this is almost zero, because in both
cases the unescaped ID ends in double quotes. Within these double quotes
not many characters must be escaped, essentially only double quotes and
backslashes. Neither can appear in an ID (more precisely: neither should).
Proper escaping is "the right thing to do" anyway.
Change-Id: I21934f7cb54e2d68013a994150a92c76ef1b61d7
This gives the code a little more structure without changing anything
it does. A section is extracted as a named function, and some lines
are moved and bundled where it made sense.
Change-Id: I51909517021bee9dc618efe5fbe40adfc29dc6af
The code before was not wrong, just deeply nested. The worst case was
that the final $upArrowLink.attr( … ) might have been called on zero
elements. jQuery is fine with this.
Change-Id: I62e7286c7fe906544fe148e1122c60cc8db070f3
The class="mw-cite-backlink" is part of a message. It should be
considered code and not be customized, but can be. Frwiki for example
localized it.
The new code still hopes to find the class, and still hopes the first
child is the text node containing the plain text up arrow. (See the
message "cite_references_link_many" which contains all this.) This code
path is kept because it is more performant.
If the class is not found, the upwards traversal done via .closest()
stops at the <li>. It then traverses down into the firstChild nodes,
hoping to find the plain text up arrow this way.
This patch makes the code work with the customizations found in frwiki.
Bug: T205270
Bug: T210508
Change-Id: I32552ebe820ee12aea1a75aa17af11298dc7536a
This change makes the code much, much more robust. See, almost all HTML
relevant for this feature is encoded in messages. This allows unexpected
customizations that add additional HTML elements, change the order of DOM
elements, even remove class names and elements.
The <ol class="references"> is the only HTML snippet generated via code,
guaranteed to be there, and used as an entry point because of this.
Instead of the selector utilizing a "*" to detect references with "one"
vs. "many" backlinks, we check if a second backlink exists.
The .first() copies the browsers behavior to only respect the first anchor
in case an id="…" appears multiple times on a page.
The additional .length check further down is a missing sanity check,
currently relevant on frwiki where the expected class="mw-cite-backlink"
got localized.
Bug: T205270
Bug: T210520
Change-Id: Iba9aebfd01508b283933964cfb986d7239d4cf38
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
I tried to arrange the new code in a way that it is compact, but still
readable. I think it's possible to arrange it even better, but browser
tests should be added first, in my opinion.
Bug: T205271
Change-Id: I1d579ef9d2787fc43c0a8bbf61c583f602dca5d4
The separate "ext.cite.a11y" module is kept for (temporary)
compatibility with cached HTML, and should be removed in about
a month.
Browser tests will be added in a separate patch.
Bug: T205270
Change-Id: I26fe41c328157233cc5b06d38d2ba0f7b036a853
