MediaWiki REST API includes several strings that appear in the info section of OpenAPI specs. These strings are currently either hard-coded, or taken from module definition .json files. We should make these strings translatable.
Descriptions
Module definition .json files can appear in either core or in extensions. For example:
- in core: specs.v0.json
- in an extension: ReadingListsRoutes.v0.json
Either way, SpecBasedModule is used to load the module file, and related code can be found there.
The module definition .json files may include an optional description (per the OpenAPI schema). Right now, these descriptions are inserted verbatim into the generated OpenAPI spec.
Add support for x-i18n-description keys, similar to the approach we used for response bodies in T379706: [Research Spike] Create response body translation mechanism. Code similar to ResolveResponseDescription will resolve these into translated strings. Opportunities for sharing code between those usages should be considered.
If no x-i18-description key is present, but a description key is, then the description key should continue to be used, as it is now. This will maintain backwards compatibility, and also allow simpler code for extensions (including third-party ones not hosted at WMF) that do not require translated descriptions.
If both a x-i18n-description key and and description key are present, then the x-i18n-description key should be used.
Default Module
Legacy methods of registering endpoints are still supported:
- in core, via the original coreRoutes.json and coreDevelopmentRoutes.json files
- in a RestRoutes section within extension.json. For example, CampaignEvents extension.json uses this, as do most existing extensions that publish REST routes.
In these cases, the endpoints are grouped into a "default module".
The legacy formats did not support titles or descriptions. Instead, placeholder strings are hard-coded in ExtraRoutesModule::getOpenApiInfo(). We should replace these hard-coded strings with MessageValue instances that use new message keys (and add these keys to the qqq.json and en.json files, per our normal translation approach).
Other Strings
There are two additional hard-coded strings in ModuleSpecHandler ("Default Module" and "Module") that should also be made translatable.
Completion Criteria:
- module definition files support x-i18n-description keys (with testing, if possible)
- the "default module" strings are translatable (manual testing sufficient)
- the miscellaneous other strings are translatable (manual testing sufficient)