Mixing different binary boolean operators within an expression
without using parentheses to clarify precedence is not allowed (T358966)
Change-Id: I6d3edc5f8dddcfc6bd6a7d2a8f2ad9467372908d
Define the content-model-$model message which is used by
ContentHandler::getLocalizedName.
Bug: T358341
Depends-On: I0f090f21ce2b0f6d92790ae9f2b755dabb2e7082
Change-Id: I221f98cbb7d06dc667fdacedcdbe77d5781b025b
Added escapes for "!" and ";" as well as additional escapes
at beginning and end of string.
Bug: T168763
Co-Authored-By: vlakoff <vlakoff@gmail.com>
Co-Authored-By: C. Scott Ananian <cananian@wikimedia.org>
Depends-On: I34f2fa8c329e6f6771453b2f94dc4afbec31dac8
Change-Id: I6c9dcfdbbb2c6eff9414e24d3f2693ebe576505a
These errors weren't being flagged because of a bug in how
`parsoid-compatible` was handled in the parser test file options.
See Ifca13393c3bbec27c23cbdc311d4550fbccf21ca.
Change-Id: Ib65dd0adb472da53823c07af5991a140374501e4
In order to avoid misleading the caller, set some title properties to
nil for interwiki links. That value should still be falsey, but can
prevent making unwarranted assumptions about the destination of
interwiki links.
Split from I847ac4b7587b98be06b25fe14765e9efdc7b774d because this
could possibly have effects on existing modules.
Change-Id: I06efea9b264ba0f09bfb36e6bf1bb04f1cdd03e4
This allows conversion of MediaWiki-internal codes to standardized
codes suitable for inclusion in HTML.
Change-Id: I5d2102ca57cc6861b8ec144a90f9c17b630f38ce
ScribuntoContent now supports content being redirects, if the underlying
ScribuntoEngine does so. For Lua, a redirect looks like:
return require [[Module:Foo]]
which also happens to be perfectly valid Lua. There is intentionally no
`#REDIRECT`-style token (like in wikitext/JavaScript/CSS) because no one
will create a page with this content except for the purposes of a
redirect.
Bug: T120794
Co-Authored-By: DannyS712 <DannyS712.enwiki@gmail.com>
Co-Authored-By: C. Scott Ananian <cscott@cscott.net>
Co-Authored-By: Jackmcbarn <jackmcbarn@gmail.com>
Change-Id: I405e7953d00af8a34d5e8addc61a245732c71e8e
It currently inherents from the mw-parser-output div, which sets
it based on the documentation page (content language).
Change-Id: I79847cd8cfe75598c843e96a09d9aa61b00304a9
Title::castFromPageReference() and similar methods can return null
instead of Title when the parameter is null. Although that could not
happen in this code, there is no way to tell that to Phan, so
suppressions were required to avoid its warnings about possible nulls.
Instead, since MW 1.41, we can just use Title::newFromPageReference(),
which can't return null (and doesn't accept null as the parameter).
See also Ida4da75953cf3bca372a40dc88022443109ca0cb in MediaWiki core.
Change-Id: Ia3c415cdd68fe4b19869aa8eb8e816e707bb5ad6
When OutputPage/Skin call ParserOutput->getText(), this already takes
care of the appropriate attributes. This redundancy is non-obvious
however, because in this code $parserOutput is re-purposed in an odd
way that makes it seem like it has to mark its own language, so as to
separate it from the appended portions for validation error and
syntax highlighted code.
However, at least the way the code has been in recent years, this
has always been a redundant wrapper since OutputPage/Skin already
set the same attributes on the resulting container. With T341244
closed, this is more obvious now that it is located in
ParserOutput::getText, but even before I worked on T341244, the Skin
will have already been doing the same thing as this code was doing,
setting the same redundant attributes.
Bug: T350806
Change-Id: Idb8471eec5d5ac39b7a347c70f3a618eba18a57b
The ParserOutput object used here starts life as the ParserOutput for
parsing the docpage (wrapped via an interface message). In order to
remove use of the Title::getPageViewLanguage method there, we need to
re-arrange some logic such that we parse the doc page first, and see
what language it was rendered in, instead of currently where
Title::getPageViewLanguage tries to "guess" what Parser and
LanguageConverter will do.
As prep for that stop reading/writing the HTML text of this
ParserOutput object in favour of being more like the Parser itself,
which accumulates metadata in ParserOutput and calls setText only
once at the end.
* Refactor highlight() to return standalone HTML instead.
* Refactor validation error to append to $html instead.
Other improvements while at it:
* Document how stuff works today.
* Clarify variable names.
* Separate concerns better by moving responsibility of `<pre>`
fallback to highlight(), and limiting knowledge of
ScribuntoEngineBase to the caller.
Bug: T350806
Change-Id: I9fe6d93727f29c284ea21db6edd6a2b1663e8e06
Some exception messages add tracking categories, which fail when there
is no title context.
Bug: T351045
Change-Id: I47d0160010c9da5a9a9974718a432fd5e79f8286
