Extract loadCoreData(), which loads only the core, non-mergeable keys
from the core messages files, not the extension messages files or the
JSON files. Have loadItem() call this method, skipping the full
initLanguage() + recache(), if possible.
Because compiling the plural rules takes up a significant amount of
loading the core-only data (see discussion on Gerrit), extract
readPluralFilesAndRegisterDeps() from readSourceFilesAndRegisterDeps(),
and only call the latter in loadCoreData() (while recache() calls both).
Also remove a comment about readSourceFilesAndRegisterDeps() returning
false if the localisation doesn’t exist, which AFAICT hasn’t been true
since change I35bbb3a7a1 (commit 8e0c0a9fc9) in 2014.
Note that the new “core-only data” path in loadItem() bypasses the
underlying LCStore even if the core data (or indeed all data) happens to
be present in it. Some investigation and benchmarks (see the discussion
on this change on Gerrit) indicate that this is usually a performance
win; in particular, unless manualRecache is set, just checking whether
the LCStore is expired is relatively expensive.
[For further discussion, see also changes I00f2018400 and I64822e050e on
Gerrit, which were later squashed into this change.]
Bug: T342418
Change-Id: I7ec2d87c0f864c7dbfd629f0b47f22dc8a6fa552
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]: f8b5fe95f7/gateway_common/messages/MessagesEs_419.php (11)
[3]: 2537439aee/messages/MessagesEs_419.php (11)
Bug: T342418
Change-Id: Ia3dffea390d4efdfa3a3cea549d079507718ef48
The classes were already moved in change I62c701d574 (commit
051e127bdb).
Ideally, the tests should have a namespace, but the other tests in
/language are also unnamespaced, so let’s not do that yet.
Change-Id: Ieef8728a1f474ce6b16fa534c9697e1e89a4a36d
2023-07-28 15:23:06 +02:00
Renamed from tests/phpunit/includes/cache/LocalisationCacheTest.php (Browse further)
