LocalisationUpdate doesn't work well with languages with fallback
Closed, ResolvedPublic
Actions

Assigned To

None

Authored By

	liangent
	Oct 27 2011, 4:49 AM

Description

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.

Version: unspecified
Severity: normal

Details

Reference: bz31982

Event Timeline

• bzimport raised the priority of this task from to Needs Triage.Nov 21 2014, 11:56 PM

• bzimport added projects: MediaWiki-extensions-LocalisationUpdate, I18n.

• bzimport set Reference to bz31982.

• bzimport added a subscriber: Unknown Object (MLST).

liangent created this task.Oct 27 2011, 4:49 AM

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
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.

Attached:

bug31982.patch924 BDownload

(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.