It's elitist mathematical jargon. In all cases dealt with here, it adds
no additional meaning compared to "if", beyond what was already obvious
from context. Thus, its only purpose is to smugly demonstrate that the
author attended their second-year mathematics classes, at the expense of
causing confusion for everyone who doesn't have such a background.
If you really think you need to convey extra information beyond what
"if" gives you, the English language contains plenty of devices for doing
so, without resorting to neologisms.
Change-Id: Iae21095d02ec2935c10e94f532235c2671c115b1
Functions expect the message cache to return a string if a message
exists, even empty, and false if it does not exist. This adds casting
to the substr() function, which would return false for existing
messages that were just blank.
Bug: 14176
Change-Id: Id91914a3701fe53f1e2e894824512489392c628b
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
languages, first checking on-wiki and then checking the CDB cache,
until it finds the message. Note that fallback languages never
take precedence over the actual requested language.
This patch was taken from the following changes and then
adjusted to fix issues that caused bug 46579.
* Change-Id: Iaaf6ccebd8c40c9602748c58c3a5c73c29e7aa4d
- Author: Matthew Walker <mwalker@wikimedia.org>
- (cherry picked from commit d434bfcf3b)
* Change-Id: Ib607a446d3499a3c042dce408db5cbaf12fa9e3d
- Author: Mormegil <mormegil@centrum.cz>
- (cherry picked from commit 1b8cb8dc31)
Bug: 1495
Bug: 46579
Change-Id: I420457863eeb79824698d06abc7784032b267af2
[includes/cache/MessageCache.php]
- internal constants
- constructor
- a few missing @var
[includes/clientpool/RedisConnectionPool.php]
- group internal settings applying to the pool
- misc protected members updates
[includes/debug/Debug.php]
- missing parameter name in @var statements
Change-Id: I6ff0a68d659529d128f40f32b0fd1c1d39af952f
Remove some trailing whitespace, break long lines, make PHPDoc consistent
and update it in places.
Change-Id: I340b43a47e121a44ebd4aaa2a45dff12e945e645
* Use the stale message cache while the new one is being generated
* Revert I811755d4 (make message cache load failure fatal). This
escalated several very plausible temporary site issues from barely
noticeable to complete downtime -- for example, memcached being down
on a site with only one memcached server.
* Remove $wgLocalMessageCacheSerialized, it's always been pointless
* Clarify a couple of comments.
* Increased lock wait timeout to 30s
* Make lock() fail immediately on memcached connection refused
Tests done:
* With local cache enabled: normal cold refill; refill local from
global cache; use stale local cache during remote refill; use stale
global cache during remote refill; cold cache wait for remote refill;
saveToCaches() failure; memcached connection refused.
* With local cache disabled: saveToCaches() failure; cache disabled due
to "error" status key; memcached connection refused.
Setting a 1-day expiry in memcached, with a ~10s CPU cost to replace, is
not the best idea since it inevitably leads to a cache stampede. Dealing
with the stampede by waiting for a lock is not ideal, even if it were
implemented properly, since it's not necessary to deliver perfectly
fresh message cache data to all clients.
This is especially obvious when you note that barring bugs, expiry and
regeneration always gives you back the exact same data, because we have
incremental updates (MessageCache::replace()). Keeping all clients
waiting for 10s just to give them the data they have already is pretty
pointless.
So, continue to serve the site from the stale message cache while the
new one is being generated.
One caveat: if local caching enabled, when the message cache becomes
stale, a sudden spike in network bandwidth may result due to the full
array (also typically stale) being fetched from the shared cache.
Bug: 43516
Change-Id: Ia145fd90da33956d8aac127634606aaecfaa176b
This patch set reverts the following:
* Iaaf6ccebd8c40c9602748c58c3a5c73c29e7aa4d
* Ib607a446d3499a3c042dce408db5cbaf12fa9e3d
* Ic59fd20856eb0489d70f3469a56ebce0efb3db13 (partially)
Bug 46579 comment 17 describes a desired solution. In
If88923119179924a5ec091394ccab000ade16b3e we are working on a fix, but it is
taking longer than we anticipated. There was a deployment window planned
about now, but we didn't make it. It makes sense to revert for now, and commit
a proper solution somewhere next week.
Bug: 46579
Bug: 1495
Change-Id: Iac7ac4357dd80e8cdb238a6a207393f0712b3fe5
After Iaaf6cceb, MessageCache::get() goes through the fallback chain,
which is unwanted for conversion tables (for example, we don't want
zh-hans table for zh, where zh means "no conversion"). Since the only
needed feature is to fetch text from MediaWiki namespace (conversion
tables in PHP are stored somewhere else), it is now changed to use
MessageCache::getMsgFromNamespace() instead to avoid fallbacks.
Change-Id: I46e0be31c9c0fe0a6e4923fc1aff0fbbadbf1d67
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
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.
