Commit graph

5 commits

Author SHA1 Message Date
C. Scott Ananian
06ab90f163 Add new ParserOutput::{get,set}OutputFlag() interface
This is a uniform mechanism to access a number of bespoke boolean
flags in ParserOutput.  It allows extensibility in core (by adding new
field names to ParserOutputFlags) without exposing new getter/setter
methods to Parsoid.  It replaces the ParserOutput::{get,set}Flag()
interface which (a) doesn't allow access to certain flags, and (b) is
typically called with a string rather than a constant, and (c) has a
very generic name.  (Note that Parser::setOutputFlag() already called
these "output flags".)

In the future we might unify the representation so that we store
everything in $mFlags and don't have explicit properties in
ParserOutput, but those representation details should be invisible to
the clients of this API.  (We might also use a proper enumeration
for ParserOutputFlags, when PHP supports this.)

There is some overlap with ParserOutput::{get,set}ExtensionData(), but
I've left those methods as-is because (a) they allow for non-boolean
data, unlike the *Flag() methods, and (b) it seems worthwhile to
distingush properties set by extensions from properties used by core.

Code search:
https://codesearch.wmcloud.org/search/?q=%5BOo%5Dut%28put%29%3F%28%5C%28%5C%29%29%3F-%3E%28g%7Cs%29etFlag%5C%28&i=nope&files=&excludeFiles=&repos=

Bug: T292868
Change-Id: I39bc58d207836df6f328c54be9e3330719cebbeb
2021-10-15 14:25:54 -04:00
C. Scott Ananian
1c9bbfc14e Language: hard deprecate the noSeparators parameter to ::formatNum
Code should use Language::formatNumNoSeparators() instead, which has
existed since MW 1.21.

Code search:
https://codesearch.wmcloud.org/search/?q=formatNum%5C%28%5B%5E%29%5D*%2C&i=nope&files=&repos=

Depends-On: I95c365e2535bb3c47bed69a9b702c8f13d9fab87
Depends-On: I012434d5f6c749fec45a6c160e8d5d03686192e9
Depends-On: If3de5645a92514f605d4117fea3a820ed6c86624
Change-Id: I58a66975e505f16d8db5d663a9ca225535277983
2020-10-21 10:08:04 -04:00
C. Scott Ananian
9bd4fc0ae9 Revert "Adding = as a parser function"
This reverts commit 4bc0dc348a.

Reason for revert: Dutch Wikitionary uses {{=}} for something else;
see https://phabricator.wikimedia.org/T91154#6276915 for details.

Revert for now so it doesn't disrupt next week's train, we'll add it back with a config var or some other mitigation.

Bug: T91154
Change-Id: I9f81c7b73a04d6c1d77b67ce311cc7e6d279eb8b
2020-07-03 14:52:27 +00:00
Base
4bc0dc348a Adding = as a parser function
Bug: T91154
Change-Id: I8c9df0a8ce07e1febef137946615efd74d4800e3
2020-07-01 14:20:37 -04:00
Tim Starling
a30b328bd4 Rename CoreMagicWords to CoreMagicVariables and update docs
There's already a thing called magic words, and this is not it. These
things are called variables. There are many usages of this term in the
source. The term was introduced by Lee in 2002: originally
OutputPage::replaceVariables() contained only this functionality.

I introduced the term "magic word", meaning a localizable keyword.
Localizable keywords are an abstraction not limited to this use case.

"Magic variables" is a neologism, but I suppose it is permissible, since
it disambiguates. Whereas calling a variable a magic word conflates rather
than disambiguates.

Fix terminology in magicword.md and update the examples.

Change-Id: I621c888e3790a145ca9978f6b30ff1a8f685b64c
2020-06-11 13:28:45 +10:00
Renamed from includes/parser/CoreMagicWords.php (Browse further)