Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Iae45fa269363be8ee05c598ea6926514ce817762
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
Trigger a deprecation warning if MessageCache::get gets called without
a Language object. On omitted parameter still the content language is
used.
Also change from $langcode = true to $language = null. This allows to
introduce a PHP type check in I8d0de2c7c2e6d087228844874d8251933b4acea4.
Change-Id: Ib27cfc0af090790daca3995fb1c3d78712d53ae6
which takes two timestamps in order to calculate a more accurate text representation of the duration between the timestamps
Bug: T219397
Co-authored-by: addshore <addshorewiki@gmail.com>
Co-authored-by: Silvan <silvan.heintze@wikimedia.de>
Change-Id: I290f8da815f9571dae75fddde2da2010cc9a7fec
A number of tests have hardcoded expections that pass only in WMF CI
where Quibble has LocalSettings.php with $wgScript and $wgArticlePath
set a certain way.
We could fix these by adding setMwGlobals() in their tests, as we
often do, but these are so often forgotten that I'd rather we just
add them to TestSetup.php so that it is simply impossible to write a
test that that passes locally for you (if you have the same config)
but not for someone else.
There is a larger project in there somewhere about expanding this
slowly such that we basically only pluck DB-settings and extension
enablement from LocalSettings and otherwise run the tests with the
default settings in PHPUnit. Pretty much by definition, any (other)
setting you have in LocalSettings is irrelevant because it either:
1. has no effect on the test (majority, harmless either way),
2. has a custom default via TestSetup.php (which has precedence over
LocalSettings.php),
3. is relevant to the code being tested and the test case correctly
calls setMwGlobals() to ensure a consistent value during test.
4. is relevant to the tested code but has no override, thus only
passes if you happen to have the "right" value set for it
(undesirable).
Case 4 is already categorically impossible for the most common config
settings that influence random code because we give them a value
in TestSetup.php. This patch expands that to include $wgScript
and $wgArticlePath. Perhaps in the future we can think about a way
to do this automatically by either re-applying MainConfigSchema
(sans db settings) or by only selectively applying LocalSettings.php
in the first place.
This patch follows-up I072ddf89562fe, which added a test case in
WikitextContentHandlerIntegrationTest.php that assumed "/index.php"
as the value of $wgScript. This passes in WMF CI since Quibble uses
that value, but the tests failed in most local development installs
since those tend to use "/w" instead.
Rather than one-off fixing that one test with overrideConfigValues(),
switch to a more general fixture, since the precise values don't
matter for this test.
Bug: T349087
Bug: T277470
Change-Id: If4304b7ca4a838bd892d4516a0b5c6dfbc30986e
I think there is further room for improvement
here, such as a method that takes 2 points in time
and gives you a more precise summarization of the duration
in terms of actual dates.
(And we will do this in a followup)
To avoid changing behaviour where this method is called
the default interval of `month` is not specified, so
existing calls return as they did before.
For callers that want `month` granularity, they can
specify month.
Bug: T219397
Change-Id: I5a07e14629fd9f67b1f17df3db75b68f98295dfb
Requested by the zgh community in the Wikimedia Incubator at [1];
the converter is the same as for Shilha (`shi`); the main difference
between the two languages is that the main script for `zgh` is
Tifinagh, which can't be losslessly converted to the Latin script
(the former is unicameral, the latter is bicameral), so the
converter and configuration added here is essentially one-directional.
[1] https://incubator.wikimedia.org/wiki/Special:PermaLink/6060805
Change-Id: I483a1594f001226439497f0870176e9a1e447458
* Removed 'zh' from all variants to prevent unexpected conversion
(e.g., Hant in zh-cn converted to Hani with
-{H|zh:Hani; zh-hant:Hant;}- ,
which was referring to
-{H|Hani=>zh-hant:Hant; Hani=>zh-tw:Hant; Hani=>zh-hk:Hant;
Hani=>zh-mo:Hant;}-
instead of
-{H|zh-hans:Hani; zh-hant:Hant;}- )
Bug: T352554
Change-Id: I58db0f92e911dcce38beb2d9835681a8158328db
The TranslationAliasesDirs configuration allows defining translatable
aliases in JSON files. The value should be a name or names of folders
that contains files that have localized aliases. Each language should
have a separate file.
Currently, it supports defining special page aliases but in the
future can be extended to support magic words and namespace aliases.
The patch adds a script: ConvertExtensionsMessagesToTranslationAlias
that can be used to convert existing ExtensionMessagesFiles to the new
format.
Bug: T89947
Change-Id: Ief16a48a8dc8742854f67301791aa2a0b0531116
Fix the fallback chain for the language converter for zh by:
* Changed fallback order into
* zh-hk' <=> 'zh-mo' first, 'zh-hant' second
* 'zh-sg' <=> 'zh-my' first, 'zh-hans' second
* Added 'zh' to all variants (except 'zh') to reduce
"converter-manual-rule-error" messages
('Error detected in manual language conversion rule').
Bug: T352554
Change-Id: Ia006c0cb00bcc809f32267b1c1feca773daadb3b
MediaWiki only supports 14 character timestamps, and most date input
fields accordingly limit the accepted input range to fit within that
constraint, so the largest acceptable date is 9999-12-31 23:59:59.
However, if an user's own timezone preference is set to a timezone with
a higher offset than the server timezone, such dates may overflow into
the year 10000 and cause an error ("The timestamp XYZ should have 14
characters"). This very commonly happens when an admin decides to block
an user until 9999-12-31 instead of using the infinite expiry for some
reason, effectively breaking the block log for every user with a
timezone offset higher than the server offset.
Making MediaWiki support dates beyond the year 10000 would be a larger
undertaking, so for now, limit the impact of this problem by ensuring
that userAdjust() does not generate a local date that sprintfDate()
would not be able to handle.
Bug: T32148
Bug: T277809
Change-Id: I17ceee6c80dcc1559c6d66f1956ba1f0a4b519a3
Special pages belong to the interaction layer, lower level code should
not access them. That is especially true for something used everywhere
in the code base, like Language.
Change-Id: I46a2a7d60ff73dac3ce72e657c6232b6168a98e8
Two messages were added to wgRawHtmlMessages instead of just
fixing the way they were parsed so they can't contain raw
HTML. This fixes that.
In order to avoid breakage on-wiki for old customized messages
that took advantage of them being parsed as raw HTML, rename
the messages too. Also rename a few other messages from the
same set to stay consistent.
Note: These messages are suppressed in favour of Echo's messages
when Echo is enabled, and Echo is enabled on all Wikimedia wikis,
so the existing customized messages on Wikimedia wikis are basically
no-ops.
Bug: T353316
Change-Id: Ib0d1c79247fe091f2806b7c23ffb2fe22cc4df4a
Changes to the use statements done automatically via script
Addition of missing use statements and changes to docs done manually
Change-Id: Ib326ae1e5c8409a98398c721e8b8ce42c73bd012
There are a couple of user options related classes already,
and the T321527 work on dynamic defaults is going to add
even more. Let's move them into a separate namespace
to make core a bit more organized.
Old name is kept as an alias for compatibility purposes.
Bug: T321527
Bug: T352284
Change-Id: I9822eb1553870b876d0b8a927e4e86c27d83bd52
This has been constantly mentioned as buggy and broken and there is no
official version of latin or Arabic (see the ticket for more details).
This can be turned back as an extension if needed by third party users.
Bug: T350684
Bug: T268143
Depends-On: I6180dca2c49b3119751766268acc56087aaf8414
Change-Id: Ifbf3c8954d885daf891f8d9efc11743d898302f0
This was done automatically using the
`Universal.WhiteSpace.CommaSpacing` sniff, which will be included in the
next release of the MW PHPCS config.
Some of these have been adjusted manually where the autofix broke
vertical alignment.
Change-Id: I54a4668d8a2759b9d7de47742c943a535a04e211
Use
$this->getServiceContainer()
instead of
MediaWikiServices::getInstance()
in tests where possible.
Change-Id: I798b2941f37a43b9073072935b54c3ea0cfe70dd
This creates a new language code, 'x-xss', which is enabled using the
setting $wgUseXssLanguage (similar to how $wgUsePigLatinVariant enables
the 'en-x-piglatin' language code, and likewise defaults to false; will
be enabled in development settings soon).
In this language code, all messages become “malicious”, trying to run
some alert() JavaScript; if any alert() actually fires in the browser,
the message was not escaped properly. ($wgRawHtmlMessages are exempt,
since they’re already known to be “unsafe” and require more rights to
edit on-wiki.) Messages that are not escaped properly are generally a
minor security issue; they effectively let a user with 'editinterface'
right (such as a sysop, on many wikis) run arbitrary JS, without needing
the 'editsitejs' right (normally restricted to interface admins).
Developers can use this language code to more easily check their code
for escaping issues / cross-site scripting vulnerabilities.
Bug: T340201
Change-Id: Ia9a1cf712b139fea5da72046e37035e6de39d8d5
On LanguageNameUtils, the method is called getLanguageName(), not
fetchLanguageName() like on Language.
As far as I can tell, this must have been broken since change
I016b1c1731 (commit 0f935809fd). It might have worked in MediaWiki core
CI because the cldr extension isn’t installed there (and thus the test
is skipped); I have no idea why it seemingly didn’t break cldr’s own CI;
but locally, the test consistently fails.
Bug: T325962
Change-Id: I0a2ff0a41ebe4f3007316e4511926f6b10c71e1d
