In change I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83 I am planning to
make Wikimedia\Message\MessageValue use it, and we try to pretend that
it is a library separate from MediaWiki, so it makes sense to move
MessageSpecifier to the same namespace under Wikimedia\.
Bug: T353458
Change-Id: I9ff4ff7beb098b60c92f564591937c7d789c6684
We have some code that expects that if you disassemble a
MessageSpecifier using its getKey() and getParams() methods,
then assemble a new MessageSpecifier using the return values,
you will get (at least approximately) the same message.
This was not the case with RawMessage, even though it implements
the MessageSpecifier interface, because its "keys" are not real
message keys, and this operation would mess it up.
Override the MessageSpecifier methods on RawMessage so that they're
compatible with how everyone expects a MessageSpecifier to work.
Add some tests for OutputPage, Message\Converter and Status
to verify some scenarios that would previously have failed.
Depends-On: I41991989515b4791bc1746f26bd404bf4f17dbdb
Depends-On: I612361dd20ff8aad4c0069f1c5af78e3e13b9692
Change-Id: Iddd14efa8b9536277c372257d5a7be135f26a540
Using a wikitext list results in lack of support for messages that, in
turn, contain bullet lists, as the inner list items would be put on the
same level as the outer list. So, use plain HTML instead.
Bug: T368830
Change-Id: Ie834aea8469a74c6de7374ad20882e94f674f15d
Use more specific and less fragile assertions whenever possible;
most tests don't need to examine the internals of the status so
closely. Use StatusValue::getMessages() when necessary.
Change-Id: Ie4b3ebc03abb0e352e82394ced6ab9e733c83fb4
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Iae45fa269363be8ee05c598ea6926514ce817762
Normally two Message objects can be compared with `==`, and they will
compare equal if they have the same key, parameters and internal state
such as the selected language.
However, if you call `setContext()` on a Message, it will never
compare equal to any other Message object, because a unique closure
is stored in the `userLangCallback` property.
Most implementations of MessageLocalizer::msg() use `setContext()`,
so filtering out duplicate Message objects in StatusValue usually
didn't work. Luckily most uses of StatusValue use string message keys.
Change-Id: Id22075bf73d37fd139c2ef7d80c69eeb462a7b68
Follows-up Ibc4ce11594cf36.
> We lose useful coverage and waste valuable time on keeping tags
> accurate through refactors (or worse, forget to do so).
>
> Tracking tiny per-method details wastes time in realizing (and
> fixing) when people inevitably don't keep them in sync, and time
> lost in finding uncovered code to write tests to realize it was
> already covered but "not yet claimed".
>
> Given all used methods are de-facto and liberally claimed, and
> that we keep the coverage limited to the subject class, this
> maintains the spirit and intent. PHPUnit offers a more precise
> tool when you need it (i.e. when testing legacy monster classes),
> but for well-written code, the class-wide tag suffices.
Ref https://gerrit.wikimedia.org/r/q/owner:Krinkle+is:merged+message:Widen
Change-Id: I6d66d5db2ca15441d3f26d54b0bd53913976c684
StatusValue::replaceMessage() doesn't really work if given a
MessageSpecifier, and doesn't work at all if given a MessageValue.
StatusValue::hasMessage() and ::hasMessagesExcept() ignore the message
parameters when searching if given a MessageSpecifier or MessageValue.
Therefore, deprecate passing anything other than strings representing
message keys to these methods.
Change-Id: Icb4effc6c5319c12ba4ebeab447a0cef54f8e255
An array of MessageSpecifier objects is easier to deal with than the
"legacy error array" format, which is an array of whatever wfMessage()
accepts, which can be a bunch of different things.
Deprecate some existing getters.
Change-Id: Ibc4ce11594cf36ce7b2495d2636ee080d3443b04
The array spread operator is documented to behave identical to
array_merge. The syntax is just much shorter and easier to read in
situations like this, in my opinion.
Change-Id: I3b016e896e552af53d87d5e72436dc4e29070ce1
The result of wfEscapeWikiText() did not consider inclusion of a string
within table context, and so `!!` and `!` at start of line were not
previously escaped.
Additionally, if you are inserting the result of wfEscapeWikiText()
into a wikitext string, the result can inadventently form new tokens
at the left and right edges. For example:
{|
|<escaped string>
When the escaped string starts with a `-` or `+` it forms the `|-` or `|+`
token and changes the parse.
On the right side:
<escaped string>_FORCETOC__
is not a magic word unless the escaped string ends with a `_`.
Token-gluing can also occur with the double newline token denoting
a paragraph separator.
This patch adds additional cases to wfEscapeWikiText to armor
its output against all contexts in which the output may be
inserted.
Depends-On: I56147520620d56a4b98c2f22d1f469b49aed761f
Change-Id: I34f2fa8c329e6f6771453b2f94dc4afbec31dac8
Use modern array destructuring and such to make the code – so I
hope – much more readable.
Also fix a mistake in the Status test setup. This caused the mocked
Message::getParams() to return an array with string keys. This is
impossible in non-mocked scenarios. There is an array_values() call
in the Message constructor that doesn't allow string keys.
Change-Id: Ief09feb06c60d3ffbfa95fa8ef56b4a9829da680
This takes us one step closer to deprecating Status,
so we can isolate StatusValue from presentation logic.
FormatterFactory is introduced as a mechanism for
getting instance of formatters that need access to the user interface
language and other request dependent information.
Usage is demonstrated in thumb.php, SpecialCreateAccount, and
SearchHandler. The examples indicates that there is no work do
be done around ErrorPageError and LocalizedHttpException.
Change-Id: I7fe5fee24cadf934e578c36856cc5d45fb9d0981
