| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new block in testRecacheExtensionMessagesFiles() covers the
underlying issue of T343343 and T343375; see change Icc3324aca7 for an
explanation of the issue.
In order for this test to not crash, we also need to adjust some of the
other tests and data. MessagesEn.php defines $preloadedMessages, and
LocalisationCache assumes (quite rightly so, really) that all of these
messages will be found in the configured MessagesDirs. But in the test,
we override MessagesDirs to point at the test’s JSON files, while still
using the original MessagesEn.php with its $preloadedMessages. Now that
we are triggering the preload mechanism (I think it wasn’t reached by
the tests previously?), it triggers a PHP deprecation (since PHP 8) on
the missing messages, which makes the test fail:
> explode(): Passing null to parameter #2 ($string) of type string is deprecated
I decided to fix this by adding fake entries for all $preloadedMessages
to the test en.json file. This makes the other tests that compare the
entire messages array fail, so instead only compare the three messages
those tests care about ("present-*"). I don’t like this very much, but I
dislike the other two approaches I can think of even more: check
defined( 'MW_PHPUNIT_TEST' ) in the original MessagesEn.php file, or add
a test-specific MessagesEn.php using the Language::getMessagesFileName
hook.
Bug: T342418
Bug: T343343
Bug: T343375
Change-Id: Iee11cb5c52cb9dd777b70a1daa06f41f2c3ca187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, it was technically possible to set some keys in extension
messages files that didn’t make much sense (e.g. $rtl['en'] = true;).
This prevents optimizing language creation, so going forward, we will no
longer support that; ALL_KEYS is now split into CORE_ONLY_KEYS and
ALL_EXCEPT_CORE_ONLY_KEYS (with a test verifying that no key is missing
or overlapping or anything), and ALL_EXCEPT_CORE_ONLY_KEYS are silently
skipped when loading extension messages files.
To demonstrate that it’s okay to silently skip these keys, patch set 1
of this change on Gerrit instead raised a deprecation warning; CI
indicated that this warning was never hit. Codesearch [1] also suggests
that no known extension was actually using any of these keys. (The
DonationInterface [2] and LandingCheck [3] codesearch results can be
ignored: both of these define es-419 as a new language, using the
Language::getMessagesFileName hook to register their MessagesEs_419.php
as a “core” message file, not an extension message file.)
[1]: https://codesearch.wmcloud.org/search/?q=^\%24(fallback|rtl|(digit|separator)TransformTable|fallback8bitEncoding|link(PrefixExtension|Trail|PrefixCharset)|date(Formats|Preferences|PreferenceMigrationMap)|defaultDateFormat|digitGroupingPattern).*%3D&files=\.php%24
[2]: https://gerrit.wikimedia.org/g/mediawiki/extensions/DonationInterface/+/f8b5fe95f77c8a9bc516bc52084d001477c70e2d/gateway_common/messages/MessagesEs_419.php#11
[3]: https://gerrit.wikimedia.org/g/mediawiki/extensions/LandingCheck/+/2537439aeebaf6ccc71b897fa683cdc4d06ae9d3/messages/MessagesEs_419.php#11
Bug: T342418
Change-Id: Ia3dffea390d4efdfa3a3cea549d079507718ef48
|
|
|
|
|
|
|
| |
To ensure that Ia3dffea390 and I7ec2d87c0f don’t change this behavior.
Bug: T342418
Change-Id: I4646b1c84116f51b6c2a826a41dc5c975d3d205c
|
|
|
|
|
| |
Bug: T39314
Change-Id: I7c72702524bb75bb939a30b6c8e451ae8f89e906
|
|
Currently LocalisationCache merges the core data for all languages in
the fallback chain, then the extension data, then merges those two, and
then gives extensions like LocalisationUpdate a chance to make final
overrides with the LocalisationCacheRecache hook.
But if LocalisationUpdate doesn't want to locally duplicate all the
messages for every language (e.g. r104041), LocalisationCacheRecache is
too late: the information as to whether a message came from the primary
language or a fallback has been lost, so when LU itself has an override
for a fallback language it can't know whether or not the existing
message should be overridden or not.
The solution is for LocalisationCache to gather the data for each
fallback language separately, call a new hook for LU to affect just that
language (LocalisationCacheRecacheFallback), and only then merge the
fallback languages together.
Bug: 68781
Change-Id: Iacfe96063fcc66c1f97ca5e5292a8fc70af988cf
|