This was mentioned to my Tim Starling a while back and I didn't add a description hoping he'd add it in his own words since I didn't have full details about what he was envisioning.

Confirmed. The banner bodies are namespaced under "MediaWiki:Centralnotice-template-", and message fields are under "MediaWiki:Centralnotice-(templatename)-", but there could be collisions with builtin CN messages.

Not sure that will ever become a problem, it would take some very odd banner naming to cause a collision.

thewub.wiki wrote:

*** Bug 42488 has been marked as a duplicate of this bug. ***

Hope that the new system can have a better fallback chain.

Could you clarify the fallback chain issue Liangent?

(In reply to comment #5)

Could you clarify the fallback chain issue Liangent?

Currently CN fetches message with wfMessage() which doesn't really go through the fallback chain (like zh-cn -> zh-hans -> zh -> en) when getting a message from database (instead it uses zh-cn -> en). This has been logged as a bug in i18n system but was never fixed. If CN turns to its own message fetching code it can avoid this issue of wfMessage().

(In reply to comment #5)

Could you clarify the fallback chain issue Liangent?

Direct effect: stewards have to populate /zh-cn, /zh-hk, /zh-mo, /zh-my, /zh-sg, /zh-tw, /zh-hans, /zh-hant and /zh subpages (9 in total) instead of simple /zh-hans and /zh-hant (2 in total).

(In reply to comment #6)

This has been logged as a bug in i18n system but was never fixed.

It's bug 1495. Sorry for spamming with comments.

wmf.amgine3691 wrote:

Wouldn't it be better to fix the known bug in i18n than replicate functionality?

(In reply to comment #9)

Wouldn't it be better to fix the known bug in i18n than replicate
functionality?

First, fixing that issue is not the goal of this new-namespace design. It's just something "we should notice or remember" when implementing this new namespace. Second, that issue may be not so easy to fix (otherwise it shouldn't be living there for such a long time...) Anyway you're welcome to fix that bug. :)

Copying the stats from bug 42488 comment 0:

The CentralNotice extension currently uses the MediaWiki namespace for storage.
Today, Meta-Wiki has 53,320 pages in the MediaWiki namespace; of those, 51,147
begin with "Centralnotice".

mwalker wrote:

(In reply to comment #6)

Currently CN fetches message with wfMessage() which doesn't really go through
the fallback chain (like zh-cn -> zh-hans -> zh -> en) when getting a message
from database (instead it uses zh-cn -> en).

Not that this really helps, but I have about five i18n patches for CentralNotice in a holding pattern until after the fundraiser. One of which addresses this exact issue. I looked at fixing the core i18n code and though doable it was a more significant investment of time than I wanted to expend at the time I wrote my patch. Seeing as I'm waiting till January to deploy this patch set anyways I can probably go and fix the bug in core.

• As to moving things to their own namespace. With the deployment of the CN i18n stuff we will in fact have our own namespace but it will be as a scratch space for the translate extension. Once it's been marked as translated/approved we move it into MW again. I kept it this way for backwards compatibility reasons (mostly that I didn't want to have to write code to look in multiple locations for the banner.)

@Aklapper - I am going through older phabs that relate to Civi to assess the work ahead. Several of these subtasks have been addressed - could you please weigh in if this task is the same ask from 2012? Can we close this?

@SBurnett-WMF: Hi, not sure why you think I could help judging? :) What is "the same ask from 2012"? I only see one subtask here and that one is open? I don't see how this task is related to Civi as it's about CentralNotice?
In general you should close a task as "resolved" if it has been implemented, or "declined" if the maintainer(s)/stewards are against implementing this.