We were incorrectly handling transclusions with trailing
newlines after the template name.
This also improves handling of non-template transclusions,
e.g. parser functions like `{{int:mainpage}}`, which are
no longer mangled as if they were page names.
ve.dm.MWTransclusionNode#isSingleTemplate will now match
a template even if it's name is itself template-generated.
Logic for turning Parsoid's hrefs into page names stolen
from ve.dm.MWImageNode.prototype.getFilename.
Bug: T167613
Change-Id: Ibecf71338eb37bb3da81a7372e4ed41140a9af57
Back in de98382a55, references to MWTransclusionTableCell were introduced,
but weren't followed through on. So, actually add it. Have cellable
Transclusions use it as their type.
Bug: T144122
Depends-On: I054f12f4218102a12d7a9ea843f9c61e8825c52c
Change-Id: I367f878bfd1c58e20b62368cb78120604b48d791
Provide a utility funcition in ve.init.mw.LinkCache to do this.
Also use this in ve.ce.MWTransclusionNode/ve.ui.MWPreviewElement, and
introduce to ve.ce.MWExtenionNode
Bug: T73900
Bug: T153535
Change-Id: Ieb9a0274b8c5ae1932c431546f09d18000fa6dd9
Pretty sure this event does nothing for block images, but
if we are going to bind, bind the the ce caption node, not
the ce image node.
Change-Id: I02b5500f381e932efba87d61ccdf668cda377757
After 79ccfb9372cb57afa569036ef39ead13abfba673, MediaWiki's `<pre>`
tags get rendered as `<pre typeof="mw:Extension/pre">` in Parsoid HTML.
MediaWiki's indent-pre syntax (block indented by a single space) is
still rendered as `<pre>` in Parsoid HTML, however.
Indent-pre is still handled by MWPreformattedNode (no changes).
Introducing MWPreNode, which will handle `<pre>` extension tags,
and MWPreDialog to change its contents (and allow converting
to MWPreformattedNode).
Pieces copied from MWGalleryNode, MWLinkNodeInspector, CommentInspector.
Possible future improvements:
* Add a specific icon for MWPreContextItem
* Avoid API roundtrips for rendering (but rendering wikitext <pre>
is not as simple as it looks)
* Consider a way to insert these other than '<pre' sequence
Bug: T159900
Change-Id: I5bc4ea6e5d893736f65ef0dd43b08c18cb1a1e85
Algorithm for deciding which cells handle sorting is exactly
the same as in the real jQuery Tablesorter.
Depends on changes in VE core:
* I50426e173c68af7df49e47fe3bec0465a9a55c26
* Iabb372dfe7bf5feef314315ac74a788c6c58dc20
Bug: T139072
Change-Id: I4446be2ad459b05590754da9bb6c3dd8f796be42
This became a special case when decodeURIComponentIntoArticleTitle()
was introduced, presumably because we skipped underscore transformation
out of laziness here. It doesn't matter whether we do underscore normalization
because we do title normalization right after, so make this code
less exceptional by using the fully decoded title.
Change-Id: I036cc7f1e08895d36224c94b8edc3ad700af1947
<a href="Foo%3F"> would dirty-diff to <a href="Foo?"> and also render
as such, pointing to the wrong page.
We also called decodeURIComponent() on the href twice, which can't
have been good.
Move URI decoding and underscore normalization into
getTargetDataFromHref(), and add rawTitle for callers that need it.
Put rawTitle in the origTitle attribute, so that equivalence
comparisons (decode(origTitle) === title) work as intended.
Bug: T145978
Change-Id: I29331a4ab0f8f7ef059c109f6813fa670a2c7390
This replaces ve.safeDecodeURIComponent(...).replace( /_/g, ' ' ) . This action
is really specific to the quirks of mediawiki title processing.
Change-Id: Ia9e525c9340e6de9e485355899996c97867ccb48
Make some of the methods we currently use to render the node
static so we can re-use them before inserting. We do the evaluation
without inserting the node so as not to dirty the document and
transcation history.
In the unlikely case the request fails, just fallback to inline.
This only handles insertions for now as type changes on edit will be
very rare.
This changes the signature of insertTransclusionNode, which is used
in Cite and Citoid extensions.
Bug: T51784
Change-Id: Ibc2fc66e6866084b0a4deeb082c8a1ca412febb2
New changes:
0b7e689 FindAndReplaceDialog: don't use tabindex
17b10a5 Localisation updates from https://translatewiki.net.
a4133e4 [BREAKING CHANGE] Make whitespaceHtmlCharacters a real static property
Local changes:
* MWEntityNode: Fix lookup of whitespaceHtmlCharacters
Property is now in 'static', and use registry to look up
TextNode by symbolic name.
Change-Id: Ied8c0c6feb69141c7c53fc4cc790774dee2cb63c
Depends-On: I7537b46a9fd58dfb2bd18dc4ed469aa221b96e86
The DM side already had the mixin, the CE side was still using custom
logic that has since been moved to ce.ClassAttributeNode.
This fixes the issue of tables not getting the wikitable class in VE
as it was only applied on attribute change previously, which never happened.
Change-Id: I197347762fc9228034f7664484539e5888722bcf
VisualEditor is usually not enabled in talk namespaces... but
sometimes it is. And when users see the button to edit with VE,
they're going to click it and expect to be able to sign their posts.
This tool is only loaded on talk pages and pages in additional
namespaces defined in $wgExtraSignatureNamespaces.
Code adapted with small tweaks from my own gadget
<https://meta.wikimedia.org/wiki/User:Matma_Rex/visualeditor-signature.js?oldid=13461327>,
which is already available under the MIT license.
Changes include:
* The tool is now always visible if the wiki allows signatures in any
VE namespaces, but disabled when not allowed in the current namespace.
* Register '~~~~' sequence to insert the signature.
* Code style tweaks for stricter lint checks in this repository.
* Documentation corrections.
Swedish translation provided by André Costa (already credited
as a translator as Lokal_Profil).
Depends on changes in VisualEditor core:
* I89fe53890ab59d12260ea6b41de802c38c24e8b9
* I14cd7efac521687ea38580341ae08ddc522edeeb
Bug: T53154
Change-Id: I6be5fb2118cf3eef5098d4c5320228aa81411ccb
