| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following classes were already previously PSR4-namespaced and/or
moved from includes/ to the language component in MediaWiki core:
* RawMessage
* MessageCache
* MessageLocalizer
It feels odd for e.g. Message, the parent class of RawMessage to
be in a component by itself. See also MessageTest.php which was
already under `/tests/phpunit/includes/language/`.
There exists imho no "Message" component in MediaWiki today (e.g. no
dedicated Phabricator tag, mw:Maintainers row, or mediawiki.org
landing page describing it as its own component), and creating it
seems a bit much for these three classes, almost exclusively coupled
to one component: Language (i.e. MediaWiki-Internationalization).
As a minimal change, move the source but leave the namespaced
classes unchanged.
Bug: T364652
Change-Id: Ia3ceadda185bd883175cce18a9480f3b7cadf9ad
|
| |
|
|
|
|
|
| |
Deprecated in I492edabb7ea1d75774b45eb9fd18261b39963f9f.
Bug: T278482
Change-Id: Ie9350ed0d7b2604fb4d2f440dee66964fe198c0e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix two problems that made it difficult to convert between Message
and MessageValue, or to write code that could accept both of them,
as exemplified by the StatusValue class:
* Implement a common interface
* Use the same internal format for message parameters
While these changes should be compatible with most of existing code,
where the authors were courteous enough to simply call methods such
as Message::numParam() and not look inside the values they return,
it is potentially a breaking change for anything that depended on
the formatted params being arrays or accessed their keys.
Example patches: https://gerrit.wikimedia.org/r/q/topic:message-param
Notable changes:
* Message and MessageValue now both implement MessageSpecifier
(only Message implemented it before).
* Message::numParam() and other static methods for encoding params
now return MessageParam objects, instead of special arrays.
Use these MessageParam objects internally in Message.
* Narrow down the return type of MessageSpecifier::getParams() (it
was just `array`, allowing any type in the array). Narrow down the
types for Message::params() and MessageValue::params() to match.
* Deprecate MediaWiki\Message\Converter. As a replacement add
MessageValue::newFromSpecifier(), which is analogous to
Message::newFromSpecifier(), but without weird legacy edge cases.
* Make StatusValue::getMessages() return MessageValues. Remove code
that converted between Message and MessageValue, no longer needed.
* Update many type declarations and comments to use MessageSpecifier
instead of MessageValue, as well as a couple of tests that depended
on implementation details.
Bug: T358779
Change-Id: I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This functionality was introduced in 2021 (commit 349819dc5a)
to support the addition of UserGroupMembershipParam, which was
never used, and no other use case appeared.
Its existence is now preventing us from allowing serializing
of MessageValue objects as JSON (since the parameters can't be
guaranteed to be serializable).
Deprecate:
* method: MessageValue::objectParams()
* method: Message::objectParams()
* method: Message::objectParam()
* class: UserGroupMembershipParam
* constant: ParamType::OBJECT
* Passing Stringable objects to ScalarParam
Change-Id: I492edabb7ea1d75774b45eb9fd18261b39963f9f
|
| |
|
|
|
| |
Bug: T353458
Change-Id: I088cbc53fbcdb974e5b05b45a62e91709dacc024
|
| |
|
|
|
|
|
|
|
| |
This commit introduces PHPUnit test for the MessageFormatterFactory
class. The test ensure that the getTextFormatter method behaves as
expected in various scenarios, including handling different language
codes and message formats.
Change-Id: If54ea938cc851e4728ef70866466afdd82d56ad6
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
|
| |
|
|
|
|
|
| |
* Added ParamType::OBJECT, which allows Stringable objects to be passed into MessageValue
Bug: T278482
Change-Id: Ib4990f87d4ad70b7525d7aa05c8b97e90c121674
|
| |
|
|
|
| |
Bug: T278482
Change-Id: I45da5f73f8920b79b57c02776a05d0268d3480f2
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
|
| |
|
|
|
|
| |
No integration is needed
Change-Id: If9df5614f3e214aeeaaa190de0ea149dc0806e97
|
| |
|
|
|
|
|
| |
Result of a new sniff I25a17fb22b6b669e817317a0f45051ae9c608208
Bug: T274036
Change-Id: I695873737167a75f0d94901fa40383a33984ca55
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
|
| |
|
|
|
| |
Bug: T249045
Change-Id: Ica1e1e4788d4b9f9dfcf9f8c8b4136147d92b32e
|
| |
|
|
|
|
|
|
|
|
| |
The Action API is going to need to convert between the two at various
boundaries where it receives a Status from business logic.
Also when we make HtmlFormatter and the like, that'll initially need the
same conversion logic too.
Change-Id: Id5b216b033718f3ef38bfd4be1715218ee07bb93
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The values of the constants are supposed to match the keys used for the
corresponding special parameters to Message. This one was different.
Note the values of these constants are considered an internal
implementation detail, as is the format of the XML-ish output of
MessageValue::dump(), so we don't have to worry about compatibility
when changing it here.
Change-Id: If5a7279e661df8c13780552d1dee752215e1d497
|
| |
|
|
| |
Change-Id: I85cb709f277f37279f2edbe58a441b8a4043fb27
|
| |
|
|
|
|
|
| |
Fixes an overstrict test in ListParam, and has TextFormatter convert
to Message recursively where necessary.
Change-Id: I387754b6857fbdeedea6afd222a2fdba1ebe1a9c
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Among other things, this removed mention of MediaWiki classes from the
library and adds a README.md that attempts to define constraints for
interoperability between libraries producing MessageValues and formatter
implementations that are expected to handle them.
This also renames "TextParam" to "ScalarParam", as that seems a more
accurate name for the class.
Change-Id: I264dd4de394d734a87929cf4740779e7b7d0e04a
|
|
|
An injectable service interface for message formatting, somewhat
narrowed compared to Message.
Only the text format is implemented in this framework so far, with
getTextFormatter() returning a formatter that converts to the text
format. Other formatters could be added to MessageFormatterFactory.
Bug: T226598
Change-Id: Id053074c1dbcb692e8309fdca602f94a385bca0c
|
