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
A single test function can have multiple @dataProviders. No problem.
A @dataProvider can also be used by multiple test functions. No
problem. No need to duplicate such large pieces of code when it's
identical anyway.
Change-Id: I5aea36304ec2d1666ff2334ba883df07a70c15c5
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
This is the Language Converter from Meitei Script to Bengali Script in mniwiki.
I don't know the language. I got help from a native speaker User:Haoreima.
The original prototype was in a Python Library written by myself.
It only converts the words that have Meitei characters (U+ABC0..U+ABFF).
The original prototype is already being used in mniwiki via Gadget and a Bot.
Bug: T357853
Change-Id: I810f18050f29efa38b2a646d96644e298af47c50
Add a few missing `@group Language` tags as well.
Remove stray `@group Cache` from two classes since "Cache" is not a
MediaWiki core component (per T248519 and related tasks, we did long
ago in Bugzilla have a "MediaWiki-Cache" category, but that's since
been re-orged into BagOStuff, HTTP-Cache, and Parser/ParserCache,
and Internationalization/LocalisationCache, per the description at
<https://phabricator.wikimedia.org/project/profile/1329/>.)
Ref https://gerrit.wikimedia.org/r/q/owner:Krinkle+is:merged+message:Widen
> Given all called methods are de-facto and liberally claimed, and
> that we keep the coverage limited to the subject class, it maintains
> the spirit and intent by listing the class explicitly instead.
>
> PHPUnit offers a more precise tool when you need it (i.e. when testing
> legacy monster/god classes), but for well-written code, the
> class-wide tag is exactly what you want.
>
> 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".
Bug: T364652
Change-Id: I9cfc4c210b90bfed6fd988a2525f80f5f5ee4870
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
