aboutsummaryrefslogtreecommitdiffstats
path: root/includes/language/Message/Message.php
Commit message (Collapse)AuthorAgeFilesLines
* language: Remove LanguageFactory dependency from MessageCacheTim Starling2025-03-101-6/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that MessageParser has been split out, MessageCache has no remaining calls to Language methods except for getCode(). The only non-deprecated usage of Language is as a parameter to the callbacks registered by the MessageCacheFetchOverrides hook. Review of all MessageCacheFetchOverrides handlers in Code Search shows that none are actually using the Language parameter. None of the closures even declare a third parameter. A Language object is a complex and inefficient way to pass a language code. So: * Revert the deprecation of string language codes in the language passed to MessageCache::get(). * Pass a string code internally instead of a Language object. * Relax the validation applied to string language codes, so that it is similar to LanguageFactory. Callers were often passing a Language object with a code like "qqx" which is not a known language tag, but is allowed as a parameter to LanguageFactory::getLanguage(). * Remove the third and fourth parameters to the override callbacks. * Remove the LanguageFactory constructor parameter. Depends-On: Ic4beec7373e799e51082957ab96d26e4c692c413 Change-Id: Ia9ddb1b83a6f20d3f7cee2afaf5987dbc99ea00b
* Message: Remove distinction between 'titlestr' and 'titlevalue'Bartosz Dziewoński2025-03-041-8/+12
| | | | | | | | | This only affects unserialization: we now always unserialize both of them to a PageReferenceValue. It's unclear why they were different before, hopefully it was not important. Bug: T373719 Change-Id: I19652ccffe83278dab1c510d49b86f470d8abcf6
* Split MessageParser out of MessageCacheTim Starling2025-02-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | MessageCache has enough to do without also being a parser. Split a MessageParser class out of MessageCache and make it a service. * MessageCache::parseWithPostprocessing() becomes MessageParser::parse() because every caller wants postprocessing so it makes sense to use the shorter name for this. * MessageCache::parse() becomes MessageParser ::parseWithoutPostprocessing(). I changed the return type from ParserOutput|string to ParserOutput, which is a followup to I8a1fa84e650d920d07d74722d8059d5afeedec6b. Narrowing the return type does not break b/c so it is possible to make this change for both variants. * In the new methods, a null title is always a convenience alias for a placeholder title (Special:Badtitle). This reflects the convention in Parser::setPage(). The old MessageCache::parse() retains its b/c fallback to $wgTitle. MessageCache::transform() had the potential to fall back to the title used in the previous call, a fragile mechanism which I removed without deprecation. * For consistency, allow a string language in all new methods. * In EmailNotification, clean up an early attempt at global state avoidance. Change-Id: I05ab21508d5f8394189fd41ac6a2254ac0e0d785
* Message: Delay constructing Language objectsBartosz Dziewoński2025-01-031-12/+10
| | | | | | | | | | | | Having these huge objects attached to every Message makes it difficult to compare them in serialization tests, because they indirectly hold references to a bajillion services, which are different in the test providers and the tests, so all comparisons fail unless you reset each of the bajillion of services or delay constructing the objects. Bug: T373719 Bug: T376565 Change-Id: I373cc9ec6d44ff2c82ccf143ede12969d7ff8203
* Add $linestart to parseWithPostprocessingIsabelle Hurbain-Palatin2024-11-251-0/+1
| | | | | | | | | | | | | The call to getText in Echo::DiscussionParser (line 1293) seems a good fit for the usage of MessageCache::parseWithPostprocessing to replace it, but it is called with a $linestart parameter that we can't pass to this method anymore. Hence, we reintroduce the parameter with a default value of true as it was used in the method, using the same argument order as Parser::parse(). Bug: T293512 Depends-On: Iab08f6272b2995a42b0732ad82e73e6beb796cd7 Change-Id: Icdab9cec8b40baa090b450994fd82dcbb7a83afe
* includes/libs/Message: Add return type hints, update methodsDoğu Abaris2024-11-211-2/+2
| | | | | | | | | | | | | | | | | | | Applied return type hints to improve type safety in Message classes. Adjusted constructors to specify parameter types for consistency. Enhanced `newFromJsonArray` in `ScalarParam`, `DataMessageValue`, and `MessageParam` to clarify deserialization logic. Key updates: - Added `: string` return types for `getLangCode`, `getKey`, `dump`. - Added `: array` return type for `getParams`, `getData`, `toJsonArray`. - Revised `ScalarParam` JSON parsing to ensure a consistent return. These adjustments enhance type safety across the Message classes. Depends-On: Id7cc576693f5f1830e1d261cb13c626c901fb40f Depends-On: I260e3f526be10f7b11e5c77a1e300590c6fc5b2b Depends-On: I3c318273856d15407c71cb9b4ab7c23a0debb314 Change-Id: I7e50be91c01b4b70e1d1380651f001e35bd60523
* Merge "Add type hints to detect bool/null message params"jenkins-bot2024-11-141-3/+7
|\
| * Add type hints to detect bool/null message paramsBartosz Dziewoński2024-11-141-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | Add more precise type hints to every method I could find that takes message params as arguments, so that Phan will warn if bool or null is passed, which is deprecated (T378876). Errors found in this repository thanks to these checks are fixed in I286a4a51e879bdf61f65c87dc078621c51045bee. Bug: T378876 Change-Id: I3e0df790ff9db2fa630f82408a7254a359fe61ca
* | Remove getText usages in the vicinity of MessageCacheIsabelle Hurbain-Palatin2024-11-091-20/+9
|/ | | | | | | | | | | | | | | | | | This is the fifth patch of a series of patches to remove ParserOutput::getText() calls from core. This series of patches should be functionally equivalent to I2b4bcddb234f10fd8592570cb0496adf3271328e. Here we handle the case of MessageCache, which requires a bit of refactoring to start deprecating the fact that MessageCache::parse can return either a string (if not a top-level parse) or a ParserOutput (at top-level), which callers typically use to decide whether to run getText on the output or not. We provide a MessageCache::parseWithPostprocessing method that handles this case and runs the pipeline at the desired level, and returns a ParserOutput always. Bug: T293512 Change-Id: I8a1fa84e650d920d07d74722d8059d5afeedec6b
* Message: Document Message::rawParam(s) not take bool or nullUmherirrender2024-10-291-3/+3
| | | | | | | | | ScalarParam throws exception on bool or null No extra documentation for Stringable, it is handled by string and this simplify the doc string. At least phan takes string and Stringable the same. Change-Id: I50729c1e6faec7ef33735d4e70f78aebbb1ca2f2
* Merge "Message: Document Message::numParam(s) to take int or float"jenkins-bot2024-10-281-2/+2
|\
| * Message: Document Message::numParam(s) to take int or floatUmherirrender2024-10-281-2/+2
| | | | | | | | | | | | | | | | | | ScalarParam throws exception on bool or null, MessageSpecifier or Stringable objects should not be formatted as number Strings are allowed as numbers sometimes given as string Depends-On: Ic0369493b274de3379067745573e1f8baed56dcb Change-Id: I4c0a13cfd7d26d4212282718536be94c115a0b01
* | Make MessageValue JsonCodecable instead of JsonDeserializableIsabelle Hurbain-Palatin2024-10-281-3/+2
|/ | | | Change-Id: I8ed6498acb4657c69b58a24fc3cc45f585a31b7d
* language: Move Message classes under language/ directoryTimo Tijhof2024-10-271-0/+1606
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
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-23 07:22:53 +0000