The core function behind wfMessage() (MessageCache->get()) did not
apply the language fallback chain to on-wiki messages.
This patch has changed the behavior to iterate over all possible
on-wiki fallbacks (starting with the user's language) before
using the built-in language cache (CDB files). Previously we only looked
for the existence of an on-wiki message in the users's language.
Performance wise, using the 'ab' language ('ru', 'en' fallbacks)
MessageCache::get (Averaged over runs and calls)
New Code: ~8.5% TET (110us/call)
Old Code: ~6.5% TET ( 90us/call)
TET: Total Execution Time
Change-Id: Iaaf6ccebd8c40c9602748c58c3a5c73c29e7aa4d
Added/removed spaces after opening/before closing parentheses
Added a space after a comma
Removed unneeded parentheses in condition
Change-Id: I306091347ccaaf11dee0cdfda3019cb0c12be51b
I suspect this is the primary cause we occasionally have
* Sidebar stuck in default values
* No gadgets at all
* Main page full of <int:custom-message> occurances
Change-Id: I811755d4c250800177c4ea9e509bf6e1d13443a0
This was developed for translatewiki.net, which has but
millions of messages in MediaWiki namespace. To avoid
exploding the message cache, not all of them can be
loaded. Instead of logging what messages have been
requested, now it uses the fact that if the
message has not been customised in the
site language, there is most likely
no reason to load it in any other
language either.
Change-Id: I6dd81b3858acfd2b73332e46668d46015e99c748
This may be related to things failing on load from External Storage; however we have not yet been able to verify this.
Tweaks MessageCache::loadFromDB() and MessageCache::getMsgFromNamespace() to avoid storing empty cache entries when loading text fails.
When building initial cache if we get a failure we'll log and store a '!TOO BIG' message which requests on-demand load later.
If an on-demand load failures, we'll log and return the false through but won't update the cache with the bad value.
To enable the logging in production, set up a $wgDebugLogFiles entry for 'MessageCache'.
Note that MessageCache::loadFromDB() bypasses Revision's text entry memcaching and may cause a lot of ES fetches at once.
However any ES failures *should* already be logged in the 'ExternalStoreDB' log file.
