I'd like to start this by saying that translatable apihelp messages are great.
Some people think that all people who write software know English, and don't understand why should they be translated at all. This notion is incorrect. I heard from numerous people that they use the API for developing gadgets, and who happily use the translations of Apihelp in Special:ApiSandbox into their language—it's easier for them than to read the API documentation in English. So thanks, Anomie, for making it possible.
That said, these messages are probably read by fewer people than other user interface messages. Hence, it should be a lower priority to translate them than to translate other messages in core and extensions, which are actually seen by end users who read and edit the wikis. Apihelp messages are useful only to the developers and there are fewer developers than editors.
To actually help translators at translatewiki to do this, Apihelp messages should be separated from other user interface messages. This was already done for core MediaWiki, as well as for several extensions: UniversalLanguageSelector, Translate, ContentTranslation, Echo, Flow, and FlaggedRevisions.
This should be done for all extensions. In particular, this should be done for Wikibase, which has hundreds of apihelp messages, but there are many other extensions that need this.
This requires careful and substantial work, but the process is well-known and there are existing examples. I am therefore marking it as good first task. This involves:
- In the extension's Git repository:
- Under the extension's i18n/ directory, create the api/ directory.
- In this directory, create en.json and qqq.json files.
- Find API-related messages. Usually their keys begin with apihelp-*, apierror-*, or apiwarn-*
- Copy all the API messages from en.json and qqq.json in the i18n/ directory to en.json and qqq.json in the i18n/api/ directory
- Delete the API messages from the original json files.
- If the extension has extension.json, edit this file and add "i18n/api" to MessagesDirs.
- If the extension has no extension.json, edit its main PHP initialization file (called ExtensionName.php) and add the api directory to MessagesDirs. See the example from CirrusSearch.
- If the extension has Gruntfile.js and it has a banana section, then:
- If you edited extension.json earlier, edit Gruntfile.js in a way that reads MessageDirs from extension.json. See the example from AbuseFilter.
- If there is no extension.json, add api: 'i18n/api/' in the banana section.
- In the translatewiki Git repository:
- Split the extension configuration in these files:
- groups/MediaWiki/mediawiki-extensions.txt
- groups/MediaWiki/ExtensionsAgg.yaml
- groups/MediaWiki/Wikimedia*Agg.yaml (could be WikimediaMainAgg.yaml, WikimediaAdvancedAgg.yaml, etc.)
- Notes:
- The new API group name will be "ext-extensionname-api".
- The group with the messages for users will be "ext-extensionname-user"
- Reuse the extension's description message for the aggregate group's description field. The description message usually has the name "extensionname-desc". For example, for TimedMediaHandler the description value in the YAML file is: description: '{{Special:MyLanguage/MediaWiki:Timedmediahandler-desc/en}}'. Please check that this message actually exists on translatewiki by going to the page MediaWiki://extensionname//-desc/en (example).
- Create a new aggregate group "ext-extensionname", including the main extension and the API messages using "ext-extensionname-*"
- Put the API messages group to groups/MediaWiki/WikimediaTechnicalAgg.yaml.
- Change the entry of the old message group in the aggregate groups files to the new group name. For example, if "ext-scribunto" appeared in WikimediaTechnicalAgg.yaml, the entry must be changed to "ext-scribunto-user".
- If the previously defined message group has optional or ignored messages and api* messages appear there, move them to the new api group.
- Split the extension configuration in these files:
Examples:
- For the extensions repositories:
- For the translatewiki repositiory:
This is it. Existing translations will be migrated automatically.
See more links to patches in the checklist toward the end of the task description.
The impact for the extensions' developers will be that they'll have to add new apihelp/apierror/apiwarn messages to the i18n/api/en.json and i18n/api/qqq.json files, instead of i18n/en.json and i18n/qqq.json. As far as I can tell, nobody complained about having to do this with Echo, Flow, Translate, etc.
The impact for the translators will be that the cryptic, highly technical, and rarely-seen translatable messages in the "Extensions Used by Wikimedia" group will be separated. As of August 2018, there are more than 1900 such API messages.
Checklist:
If you are working on converting an extension, put your username in the parentheses after its name. Projects marked as (+) are up for grabs, and highly recommended if you're looking for an extension to send a simple patch for because they are among the more commonly translated extensions.
All the extensions that are used by Wikimedia were converted! Thanks to everyone who helped! A checklist for other extensions is being prepared.
- AbuseFilter (@Jayprakash12345, patch)
- AntiSpoof (@Amire80, patch)
- ApiFeatureUsage (@Amire80, patch)
- Babel (@Amire80, patch)
- BetaFeatures (@Amire80, patch)
- Bounce Handler (@Krenair, patch)
- Cargo (@Krenair, patch)
- CategoryTree (@Amire80, patch)
- CentralAuth (@MarcoAurelio - task: T214983)
- CentralNotice (@Amire80, patch)
- CheckUser (@Zoranzoki21, patch)
- CirrusSearch (@rafidaslam, patch)
- Cite (@Amire80, patch)
- ConfirmEdit (@Amire80 - complicated, Gruntfile.js has mismatching list of i18n dirs compared to extension.json, patch)
- ContentTranslation (@Amire80, patch)
- Donation Interface - Gateway Common (@Amire80, complicated - multiple message dirs already, patch)
- Echo (@Amire80, patch)
- Example (@Amire80, patch)
- ExtensionDistributor (@Krenair, patch)
- FeaturedFeeds (@Amire80, patch)
- Flow (@Amire80, patch)
- Gadgets (@Zoranzoki21, patch)
- GeoData (@Krenair, patch)
- GettingStarted (@Krenair, patch)
- GlobalBlocking (@Krenair, patch)
- GlobalPreferences (@Amire80, patch)
- GlobalUsage (@Zoranzoki21, patch)
- Graph (@Krenair, patch)
- JADE (@Amire80, patch)
- JsonConfig (@Krenair, patch)
- Kartographer (@Amire80, patch)
- Linter (@Amire80, patch)
- LiquidThreads (@Amire80, patch)
- MachineVision (@Amire80 , patch)
- MassMessage (@Zoranzoki21 patch)
- Math (@Amire80, patch)
- MobileFrontend (@Amire80, patch)
- Newsletter (@ArTrix, patch)
- OATHAuth (@Amire80, patch)
- ORES (@Krenair, patch)
- PageAssessments (@Krenair, patch)
- PageImages (@Krenair, patch)
- PageViewInfo (@Krenair, patch)
- ParserMigration (@Krenair, patch)
- ParsoidBatchAPI (@Krenair, patch)
- ProofreadPage (@Krenair, patch)
- PropertySuggester (@Krenair, patch)
- RecordWizard (@Amire80, patch)
- ReadingLists (@Krenair, patch)
- Scribunto (@rafidaslam, patch)
- SecurePoll (@Krenair, patch)
- SiteMatrix (@Amire80, patch)
- SpamBlacklist @MarcoAurelio (cf. T214367)
- TextExtracts (@Krenair, patch)
- Thanks (@rafidaslam, patch)
- TemplateData (@Zoranzoki21, patch)
- TemplateSandbox (@Amire80, patch)
- TimedMediaHandler (@Amire80, patch)
- TitleBlacklist (@Zoranzoki21, patch)
- Translate (Anomie, very old patch)
- UniversalLanguageSelector (@Amire80, patch)
- Upload Wizard (@Zoranzoki21, patch)
- UrlShortener (@Zoranzoki21, patch)
- VisualEditor (@Amire80, patch)
- WebAuthn (@Amire80)
- Wikibase Client (@Amire80, patch)
- Wikibase Lexeme (@Amire80, patch)
- Wikibase Media Info (@Amire80, patch)
- Wikibase Quality Constraints (@Krenair, patch)
- Wikibase Repo (@Amire80, patch)
- Wikilove @Zoranzoki21 (patch)
- WikimediaEditorTasks (@Amire80, patch)
- Wikispeech (@Amire80, patch)
- WikispeechSpeechDataCollector (@Amire80, patch)
A somewhat related task: T167762: Split core en.json to several files.