Last modified: 2011-12-08 14:59:38 UTC
Scenario: zh-cn falls back to zh-hans, and we normally localize nothing in zh-cn (instead we localize stuff in zh-hans and wait for the automatic fallback). LocalisationUpdate is depending on the LocalisationCacheRecache hook to integrate its own l10nupdate-*.cache patches into main l10n_cache. However after a message is updated in zh-hans (and the update is expected to be seen by zh-cn users) and caught in l10nupdate-zh-hans.cache and user is viewing zh-cn page, LocalisationCache::recache( 'zh-cn' ) is called and LocalisationCacheRecache is run with $code == 'zh-cn'. Since we localize nothing in zh-cn, l10nupdate-zh-cn.cache is (almost) blank, so nothing will be merged into $alldata by LocalisationUpdate extension. This means zh-cn users will not be able to see updates in zh-hans.
The easiest way to fix this can be adding a hook for extensions to modify raw message arrays and switching to it from the current one which modifies the processed, eg. merged with fallbacks, array in the extension.
When recache, the fallback languages should also be recached. Maybe there are only a small number of user with zh-hans on that wiki and than the language is not recached recently and than nobody see the new translation. When a message update is not visible in zh-cn, it is visible in zh-hand on that wiki?
(In reply to comment #2) > When recache, the fallback languages should also be recached. Is this true? It seems the fallback language messages are just fetched with $this->readPHPFile(). > Maybe there are only a small number of user with zh-hans on that wiki and than > the language is not recached recently and than nobody see the new translation. This is true. zh-hans and zh-hant conversion tabs (it's in the language converter, not the normal i18n system) are even hidden by default on zhwiki. > When a message update is not visible in zh-cn, it is visible in zh-hand on that > wiki? Yes, it is.
(In reply to comment #3) > (In reply to comment #2) > > When recache, the fallback languages should also be recached. > Is this true? It seems the fallback language messages are just fetched with > $this->readPHPFile(). It should, but I am not sure, if it done at the momement.
This seems only affects messages of extensions. On recache all fallbacks also recached. It works for core. When a message is changed in 'de', it is also updated in 'de-formal' (which has fallback = 'de'). But for extensions it does not work. The new messages for CategoryTree are only updated for 'de', not for 'de-formal' (for example: [[MediaWiki:Categorytree-num-pages/de]] and [[MediaWiki:Categorytree-num-pages/de-formal]]) But I have no idea, why.
Created attachment 9476 [details] handle fallback sequence and load all fallback messages from the cache Messages from files in $wgExtensionMessagesFiles are stored with all fallback messages inside the LocalisationCache (at least with 'en'). Messages from core are only stored with one fallback (the fallback of the language from the message file), but not the whole sequence. For this reason the LocalisationUpdate must also follow the fallback and has to get the cache from each fallback language. I have attached a patch to fix this. Feel free to modify the patch. Thanks.
(In reply to comment #6) > Created attachment 9476 [details] > handle fallback sequence and load all fallback messages from the cache > Thanks for your patch. I will review it on or before Monday.
Patch committed with an important modification (reversing the fallback array). As submitted, this patch would cause the fallback to override the original language, meaning that on e.g. abwiki most messages would be in ru and the ab translations would be ignored, oops :D
Thanks. I have copy the idea from LocalisationCache::mergeExtensionItem.
*** Bug 32873 has been marked as a duplicate of this bug. ***
