Setup of a new project
Verify the project
- Content fit
- Software interface messages
- Some prose is okay, such as terms of service. But they should be split into smaller parts. In some cases it can be done using translatable wiki pages here in translatewiki.net
- For large amounts of prose, it is recommend to set up Translate extension for MediaWiki yourself
- The software being translated has utility to general public. No personal websites or tools useful only to the author.
- Should be a known open source license
- Quality of strings
- Should avoid spelling mistakes, bad grammar
- No lego messages (constructing messages with string concatenation)
- Consistency with punctuation, letter casing and terminology
- Minimal mark-up inside the strings.
- Message documentation
- Applicable parts of Translating:Localisation for developers#Message_documentation
- Activity and interest (releases, contact person)
- Frequent deployment or frequent releases. Having to wait over a year without release or deployment is not acceptable.
- File format is supported
Access for delivering translation updates
- BitBucket: Give push access to translatewiki
- GitHub: Give push access to @translatewiki (Create and merge commits; pull requests are not yet supported)
- GitLab: Give push access to translatewiki
- SourceForge: Make translatewiki a developer
- Wikimedia Gerrit: See mw:Gerrit/L10n-bot
- Wikimedia Phabricator: Give push access to L10n-bot
- Other: Discuss with translatewiki.net staff (Nikerabbit or Siebrand)
- Keep alphabetical order of projects and groups in
- Place repositories under a subdirectory named after the project if multiple repositories might be added for the project
- It is recommended to mirror the
organization/repo-namepattern (as used in GitHub, for example) as the directory structure
- It is recommended to mirror the
- Read-only mirror link for configuration for currently enabled projects: https://phabricator.wikimedia.org/diffusion/GTWN/browse/master/repoconfig.yaml
- Repository management explains some of the internal commands how repositories are managed. Only translatewiki.net staff deals with them.
Message group configuration
Lots of examples under groups/ in translatewiki repo. Here's an example commit. Old but mostly still valid documentation: https://www.mediawiki.org/wiki/Help:Extension:Translate/Group_configuration_example
Some fields such as the logo filename and message group description depend on steps documented in the Wiki configuration section.
Choosing a group id:
- Practice is to use lowercase letters with dashes as level separators in case of multiple groups.
- Prefix "out-" is deprecated and should not be used for new projects.
- In case of multiple groups, the aggregate group should get the top level name, i.e. "blockly", and contain all groups named "blockly-*". Suffixes like "-0-all" are deprecated.
- Do not use comma or asterisk or question mark! These have special meaning in places which accept group patterns.
- Also avoid characters which are invalid in MediaWiki titles, as that breaks shortcuts such as Special:MessageGroupStats/foo (which may be used by the people, but not generated by Translate itself).
All message keys should be prefixed with mangler if it is likely that multiple message groups will exist at some point (remember that one file + its translations is one group).
TranslateSettings.php to register the yaml file, possibly add a new namespace (if none of the existing ones fit).
To apply the changes to translatewiki.net, do the following:
twn-update-config sudo /usr/sbin/service mw-jobrunner restart # This is important if new namespace is added! autoimport
Translating:projectname needs to be created (copy template from Translating:FreeCol or other).
A logo is highly recommended but not mandatory. Logo needs to be in Wikimedia Commons or uploaded to translatewiki.net. Vector format (SVG) is recommended to enable non-blurry display in the interface. As a fallback, high resolution raster image can be used. MediaWiki will automatically create thumbnails.
Add descriptions to Group descriptions and mark the page for translation (only translation admins can mark, ping one if it does not happen automatically in a short while). It is also okay (even preferable) to use a message key from the project's i18n files, if such exists.
Other misc things:
- Add babel templates (this is forgotten very often - the whole thing should be automatized)
- Add support categories and an alias if needed