aboutsummaryrefslogtreecommitdiffstats
path: root/includes/Message
Commit message (Collapse)AuthorAgeFilesLines
* language: Move Message classes under language/ directoryTimo Tijhof2024-10-273-1704/+0
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove deprecated MediaWiki\Message\Converter classTimo Tijhof2024-10-271-35/+0
| | | | | | | | No longer used, and no longer needed now that Message and MessageValue both implement the MessageSpecifier interface. Bug: T358779 Change-Id: I42525be1a759fa271bb7b7c746c33d325038b3f2
* Remove Message::objectParams() and related codeBartosz Dziewoński2024-10-272-104/+0
| | | | | | | Deprecated in I492edabb7ea1d75774b45eb9fd18261b39963f9f. Bug: T278482 Change-Id: Ie9350ed0d7b2604fb4d2f440dee66964fe198c0e
* Make Message and MessageValue compatibleBartosz Dziewoński2024-10-194-218/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use explicit nullable type on parameter argumentsUmherirrender2024-10-161-1/+1
| | | | | | | | | | | Implicitly marking parameter $... as nullable is deprecated in php8.4, the explicit nullable type must be used instead Created with autofix from Ide15839e98a6229c22584d1c1c88c690982e1d7a Break one long line in SpecialPage.php Bug: T376276 Change-Id: I807257b2ba1ab2744ab74d9572c9c3d3ac2a968e
* Merge "Message: Throw on invalid newFromSpecifier() params instead of ignoring"jenkins-bot2024-08-221-3/+12
|\
| * Message: Throw on invalid newFromSpecifier() params instead of ignoringBartosz Dziewoński2024-08-221-3/+12
| | | | | | | | Change-Id: Ic41476e2fd9df121414d79303f9c53b4f2f6c863
* | Merge "Message: Improve constructor docs and error messages"jenkins-bot2024-08-221-22/+9
|\|
| * Message: Improve constructor docs and error messagesTimo Tijhof2024-08-221-22/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Avoid square bracket or code syntax inside exception messages as these are difficult to search for. Rephrase as a sentence instead. * Swap order of $key docs. * Improve $key docs to emphasize message existence. Non-empty-ness is afaik a much more narrow edgecase than what this is used for in practice. * Make error message about invalid $key more globally correct instead of assuming that when an empty array is passed, the only correct value is a non-empty array, as the array may be an accident in itself, which might be more likely given how rare passing arrays as message keys is. Change-Id: Iae66a62b983d39d4ab5cc1035bd9285c9ba3311a
* | Message: Validate ScalarParam and ListParam typesBartosz Dziewoński2024-08-211-18/+1
|/ | | | | | | | | * Add getters for the lists of valid types (named cases() like in PHP 8.1 enums) * Validate that the provided type is in the list * Replace funky use of reflection in Converter Change-Id: I8da89edbb943fae8920c15b1bc6856ce97a4de7a
* Message: Improve validation for fallback keysBartosz Dziewoński2024-08-161-0/+6
| | | | | | | | | | | | | | | | | | It's an easy mistake to write: $msgSpec = [ $key, $param1, $param2 ]; wfMessage( $msgSpec ); // WRONG instead of wfMessage( ...$msgSpec ); // correct Message::newFromSpecifier( $msgSpec ); // correct If you use the wrong form, your intended message parameters are used as fallback message keys, and usually ignored (assuming your intended message key exists). It's not possible to catch this mistake in all cases, since it's all arrays of strings most of the time. But we can try. Change-Id: I0b40ad90a352dc640e64090cac4224219752dc01
* Move Language and friends into Language namespaceJames D. Forrester2024-08-101-1/+1
| | | | | Bug: T353458 Change-Id: Id3202c0c4f4a2043bf97b7caee081acab684155c
* Move remaining four classes in includes/content into Content namespaceJames D. Forrester2024-08-101-1/+1
| | | | | Bug: T353458 Change-Id: Ia0f3e22078550be410c4b87faf6aa4eabe6e270d
* Drop MessageContent, deprecated since 1.38James D. Forrester2024-08-101-15/+0
| | | | Change-Id: Ib53d4a04e6faa82b0ea553221e6c0c827f36017a
* Replace gettype() with get_debug_type() in exception messagesBartosz Dziewoński2024-07-311-1/+1
| | | | | | | | | | | | | | | | | | | get_debug_type() does the same thing but better (spelling type names in the same way as in type declarations, and including names of object classes and resource types). It was added in PHP 8, but the symfony/polyfill-php80 package provides it while we still support 7.4. Also remove uses of get_class() and get_resource_type() where the new method already provides the same information. For reference: https://www.php.net/manual/en/function.get-debug-type.php https://www.php.net/manual/en/function.gettype.php To keep this safe and simple to review, I'm only changing cases where the type is immediately used in an exception message. Change-Id: I325efcddcb58be63b1592b9c20ac0845393c15e2
* Namespace MessageSpecifier under Wikimedia\Message\Bartosz Dziewoński2024-07-282-2/+2
| | | | | | | | | | 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
* language: Improve behavior of RawMessage used as MessageSpecifierBartosz Dziewoński2024-07-161-2/+2
| | | | | | | | | | | | | | | | | | | | | 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
* Move code comment that breaks Gerrit's syntax highlightingBartosz Dziewoński2024-06-261-1/+1
| | | | | | Weird. https://phabricator.wikimedia.org/F55883982 Change-Id: I16a60c2240f6cfeb8419d42e7f512d84803036ca
* Message: Rename 'interface' prop because of syntax highlightingBartosz Dziewoński2024-06-261-9/+9
| | | | | | | | | | | | | Some syntax highlighters, in particular Gerrit's, incorrectly handle code that uses a property named 'interface' (which is a PHP keyword). https://phabricator.wikimedia.org/F55884039 Rename it to avoid problems. Message isn't '@stable to extend', so this is not a breaking change. I couldn't find any extensions that refer to it anyway. Change-Id: I6676421222921b7bb1aeeefef79dd06072c1c2ac
* Merge "Fix $msg->params( getMockMessage( … ) ) not mocking inner message"jenkins-bot2024-06-161-1/+2
|\
| * Fix $msg->params( getMockMessage( … ) ) not mocking inner messageBartosz Dziewoński2024-06-131-1/+2
| | | | | | | | | | | | | | | | | | | | When using MediaWikiTestCaseTrait::getMockMessage(), if the mock message was passed as a parameter to another non-mock message, its format() method was called, which is private and can't be mocked, and causes "LogicException: Premature access to service container" in unit tests. Call the public toString() instead. Change-Id: I8718cf7890f05c09a6e5712ee3dc4d171a6637cf
* | Add "implements Stringable" to every class with "function __toString()"Bartosz Dziewoński2024-06-131-1/+1
|/ | | | | | | | | | | | | In PHP 8, but not in PHP 7.4, every class with a __toString() function implicitly implements the Stringable interface. Therefore, the behavior of checks like "instanceof Stringable" differs between these PHP versions when such classes are involved. Make every such class implement the interface so that the behavior will be consistent. The PHP 7.4 fallback for the Stringable interface is provided by symfony/polyfill-php80. Change-Id: I3f0330c2555c7d3bf99b654ed3c0b0303e257ea1
* Deprecate Message::objectParams() and related codeBartosz Dziewoński2024-05-282-1/+9
| | | | | | | | | | | | | | | | | | | | 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
* Merge "Show overridden message keys when using &uselang=qqx"jenkins-bot2024-05-041-1/+14
|\
| * Show overridden message keys when using &uselang=qqxBartosz Dziewoński2024-04-301-1/+14
| | | | | | | | | | | | | | | | | | | | When displaying messages, the requested message key can be overridden by hooks such as 'MessageCacheFetchOverrides'. If this happened, display the overridden key when using &uselang=qqx, to help users and developers track down where a message is coming from. Bug: T363729 Change-Id: I81d814278ca810035066ce4632f617f30536f1ab
* | Don't use content language in Message::getTitle()Jon Harald Søby2024-05-011-1/+2
|/ | | | | | | | | | | | | | | Change the Message::getTitle() function to not use the wiki's content language when generating links to pages in the MediaWiki namespace. Message::getTitle() returns the uppercased version of the message name as a title object. For some languages, such as Azeri and Turkish, this can lead to some transformations we don't want. For instance, when you uppercase "i" in Azerbaijani, it becomes "İ" (dotted I), leading to links to "MediaWiki:İpbreason-dropdown" on Special:Block. Bug: T362654 Change-Id: Id37c226270c53352760790ddd461ca98920b5910
* Message: add strict type to protected Message::$languageC. Scott Ananian2024-04-101-4/+4
| | | | Change-Id: Idbb28719cc6561b236d47ca99ea2d217021981a8
* Message::inLanguage(): accept Bcp47Code as well as string and LanguageC. Scott Ananian2024-04-101-4/+10
| | | | | | | Bug: T327379 Followup-To: I982e0df706a633b05dcc02b5220b737c19adc401 Followup-To: I24932449b8c40e3a5072748d87667184f4befa67 Change-Id: Id99e5695bcfd347170cb4f2f80a557d189df6d44
* Standardise all our class alias deprecation comments for ease of greppingJames D. Forrester2024-03-191-1/+1
| | | | Change-Id: I7f85d931d3b79da23e87b4e5692b2e14be8fcaa0
* Merge "REST: Introduce trait for handling Status objects"jenkins-bot2024-03-121-3/+4
|\
| * REST: Introduce trait for handling Status objectsdaniel2024-03-121-3/+4
| | | | | | | | | | | | | | The new trait provides conveniance methods for logging and throwing errors based on StatusValue instances. Change-Id: Id7cbacb744bee79cd8a6f61291a26b36e6243053
* | message: Don't load user language when a specific language was requestedTim Starling2024-03-041-3/+35
|/ | | | | | | | | | | | | | | | | | | Message::setContext() called $context->getLanguage(), loading the user options from the database, which is unnecessary if Message::inLanguage() is called immediately afterwards. In a ResourceLoader module, RequestContext::getLanguage() throws an exception due to MW_NO_SESSION being defined. For example, an exception was thrown if any HTTP client error was encountered, since log message formatting includes a call to Message::setContext(). So defer the call to RequestContext::getLanguage() by having Message::setContext() make a closure which later fetches the language if necessary. Add an integration test which previously failed. Change-Id: I326c7e3a9492952d721fb52f1868ab9c1033e683
* Move Parser to Mediawiki\Parser namespaceSubramanya Sastry2024-02-161-1/+1
| | | | | | | | Bug: T166010 Co-Authored-By: Daimona Eaytoy <daimona.wiki@gmail.com> Co-Authored-By: James Forrester <jforrester@wikimedia.org> Co-Authored-By: Subramanya Sastry <ssastry@wikimedia.org> Change-Id: I79b4e732c45095eedbaa80afa5eb7479b387ed8a
* Namespace Message, move to appropriate directoryJames D. Forrester2024-02-144-3/+1593
| | | | | Bug: T353458 Change-Id: I088cbc53fbcdb974e5b05b45a62e91709dacc024
* user: Deprecate UserGroupMembership::getGroupMemberNameUmherirrender2022-12-211-0/+3
| | | | | | | | | | Add @since to the replacement code (349819d) Also notice UserGroupMembership::getGroupName in release notes, there was no entry in the deprecation commit fb4e7a8 Bug: T325673 Follow-Up: Ib4990f87d4ad70b7525d7aa05c8b97e90c121674 Change-Id: Iae3a26dbc0b95b0d4edb59f03126295fc67c856e
* Add Message/MessageValue user group member parameter typeTChin2021-11-161-0/+52
| | | | | | | * Added ParamType::OBJECT, which allows Stringable objects to be passed into MessageValue Bug: T278482 Change-Id: Ib4990f87d4ad70b7525d7aa05c8b97e90c121674
* UserNameUtils: use ITextFormatter instead of MessageLocalizerPetr Pchelko2020-04-132-4/+26
| | | | | Bug: T249045 Change-Id: Ica1e1e4788d4b9f9dfcf9f8c8b4136147d92b32e
* Coding style: Auto-fix MediaWiki.Classes.UnsortedUseStatements.UnsortedUseJames D. Forrester2020-01-101-1/+1
| | | | Change-Id: I94a0ae83c65e8ee419bbd1ae1e86ab21ed4d8210
* Coding style: Auto-fix MediaWiki.Comment.FunctionComment.*James D. Forrester2020-01-101-1/+1
| | | | Change-Id: Ia1b9b527f177d96c8b4a2dd658921b8557076f4a
* MediaWiki\Message: Extract Message↔MessageValue conversion from TextFormatterBrad Jorsch2019-11-263-45/+136
| | | | | | | | | | 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
* Add missing @param and @return to documentationUmherirrender2019-11-101-0/+1
| | | | Change-Id: Ibc5849cc8ea7e7c4eb30ded9c1cfa5f52187c377
* TextFormatter: Remove a pointless type checkMax Semenik2019-10-071-15/+11
| | | | | | | The function signature guarantees that this parameter can't be of any other type. Change-Id: I08f80e3ae7515f21f88b7f1f4f395ddbbb7b70ab
* lib/Message: Support MessageValue as a parameterBrad Jorsch2019-08-301-5/+14
| | | | | | | Fixes an overstrict test in ListParam, and has TextFormatter convert to Message recursively where necessary. Change-Id: I387754b6857fbdeedea6afd222a2fdba1ebe1a9c
* MessageFormatterFactoryTim Starling2019-08-282-0/+103
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
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-23 18:16:54 +0000