Allow specifying interface messages to load in gadget definitions
Open, Needs TriagePublicFeature

Description

Feature summary (what you would like to be able to do and where):

Gadget definitions should support a list of interface messages to load when the gadget is loaded, similar to "messages" for resource modules in extension.json files (code search)

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

Gadgets, particularly those on multilingual wikis or designed to be used on multiple wikis, should have translated interfaces. Interface messages can be used in gadgets using mw.msg(), but this only works if the messages are loaded first.

Most translatable gadgets store the translations in the script, which makes it difficult for translators to easily find or edit the messages. Gadgets which implement translations in this way also often don't implement fallback handling.

Adding messages to a repository such as WikimediaMessages would make them translatable on Translatewiki, but that makes it harder to use the messages. Interface messages often aren't available to the gadget by default and while there is a way to load missing messages using the API, it does not seem to be used much and creates extra network requests.

Benefits (why should this be implemented?):

It would simplify the gadget code, by not requiring it to manually load messages before running the rest of the script. This would make it easier to write/maintain translatable gadgets.

Gadgets would not need a dependency on mediawiki.api and extra network requests to load interface messages.

Using interface messages would provide automatic fallback handling.

Event Timeline

Most translatable gadgets store the translations in the script

One proposed future solution is to use message bundle, see T238386: Structured localization framework for gadgets.

Big +1 for this I've now hit this issue on two important widely used gadget efforts and have had to resort to creating my own i18n solution or hardcoding strings in a certain language which is not ideal :/