Fallback to zh is not ideal given the mutual intelligibility gap between Simplified and Traditional Chinese.

$wgTranslateDisabledTargetLanguages seems to also affect message bundles, so migration to message bundles wouldn't solve this problem by itself. It would be reasonable to exempt messages bundles from $wgTranslateDisabledTargetLanguages since variants are not implemented outside of wikitext content.

One possible temporary solution is to just turn off $wgTranslateDisabledTargetLanguages.

We could look again at putting the messages in WikimediaMessages, that'd be quicker to deploy, and we could then copy across all the translations that do get done to the extension when we're ready for that (so as to not waste translators' time).

Fallback to zh is not ideal given the mutual intelligibility gap between Simplified and Traditional Chinese.

This might be true, but the main issue is that none of the fallbacks are applied, isn't it? i.e. de-at should fall back to de but it doesn't, so /Intake?uselang=de-at shows the form in German (because there are not yet any Austrian German translations), but /Intake?uselang=de-at shows it in English but should show it in German.

For Lua module integration for Message bundle we recently wrote some code to load fallback translations: https://github.com/wikimedia/mediawiki-extensions-Translate/blob/master/src/MessageBundleTranslation/MessageBundleTranslationLoader.php#L24. We could expose this via an API that can then be used by Gadgets.

In T370230#9989106, @Samwilson wrote:

This might be true, but the main issue is that none of the fallbacks are applied, isn't it?

Sorry, yes, reading the initial report again, I see that is what they were saying.

In T370230#9989106, @Samwilson wrote:

We could look again at putting the messages in WikimediaMessages, that'd be quicker to deploy, and we could then copy across all the translations that do get done to the extension when we're ready for that (so as to not waste translators' time).

See T365525#9998963. We can use CommunityRequests! I wish we had asked sooner, hehe! I'll rewrite this task now.

It hasn't been discussed, but it might not be too late to rename the extension to Community Wishlist. If we don't, some messages will need to have overrides in WikimediaMessages.

I don't know if it's worth the bother of renaming, unless we're really keen. The only message at the moment that mentions it looks to be:

"communitywishlist-form-subtitle": " Welcome to the new Community Wishlist. Please fill in the form below to submit your wish.",

Which considering it says "new" as well will probably want to be overridden anyway.

We did talk about calling the wishes "wishes" and not "requests", but I think the extension can stay with the latter in its name.

Oh, sorry, this is talking about all messages not just the front-end gadget-loaded ones. There are more of those that use "Wishlist".

Change #1056404 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/CommunityRequests@master] Import messages from Meta Wiki

https://gerrit.wikimedia.org/r/1056404

Change #1056441 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/CommunityRequests@master] Remove all PHP code, to prepare for message-only deployment

https://gerrit.wikimedia.org/r/1056441

Change #1056441 merged by jenkins-bot:

[mediawiki/extensions/CommunityRequests@master] Remove all PHP code, to prepare for message-only deployment

https://gerrit.wikimedia.org/r/1056441

Change #1056404 merged by jenkins-bot:

[mediawiki/extensions/CommunityRequests@master] Import messages from Meta Wiki

https://gerrit.wikimedia.org/r/1056404

Change #1062716 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/CommunityRequests@master] Move to a maintenance script and add remaining messages

https://gerrit.wikimedia.org/r/1062716

Regarding moving the on-wiki messages to the extension, I'm still not sure what the best approach is for naming the messages. They don't currently have names on-wiki, and are identified by integer keys within each translatable page.

For example, for <translate><!--T:23--> No supporters yet.</translate> in {{Community_Wishlist/Focus_area/Full}}, the simplest solution is to import this as "communityrequests-focus-area-full-23": "No supporters yet." but that's not a terrific name to actually use in the extension (and on wiki). It might be the easiest approach for now because we want to be able to import the messages into the extension and then re-import them regularly until we're ready to switch over to using them.

Change #1062716 merged by jenkins-bot:

[mediawiki/extensions/CommunityRequests@master] Add remaining i18n messages

https://gerrit.wikimedia.org/r/1062716

samwilson opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/259

Use status messages from CommunityRequests

samtar merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/259

Use status messages from CommunityRequests

Change #1076090 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/CommunityRequests@master] Add missing 'unknown' wish type label

https://gerrit.wikimedia.org/r/1076090

Change #1076090 merged by jenkins-bot:

[mediawiki/extensions/CommunityRequests@master] Add missing 'unknown' wish type label

https://gerrit.wikimedia.org/r/1076090

samwilson opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/269

Switch more messages to use CommunityRequests

samtar merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/269

Switch more messages to use CommunityRequests

I think this is all done for now. There are more messages to move, and of course be more edits to them as we migrate other bits to the extension, but that can all be done as part of the relevant tasks I think.