Meta:Translate extension
In Meta-Wiki there are many messages that are of such an importance that we need them to be translated in many languages. Translation is a process involving many steps by many people who do not necessarily understand each other well, but who can work together when the process itself is designed to consider tasks and roles. The Translate extension is the MediaWiki tool designed for these needs.
Introduction
[edit ]When a text is chiselled in stone, it is obvious what the source text is. However, the translation industry thrives on the many changes, that are the result of evolving consensus and / or the arrival of new facts and figures. The Translate extension is designed to cope with an evolving continuity. Originally it was developed to support the localisation of the MediaWiki software, but it was extended with a page translation feature, that was first used on translatewiki.net. Its first big implementation supports the KDE documentation on userbase.kde.org and it is now in production on Meta as well.
The page translation feature has been modelled on the work flow and the tooling used by professional translators. In order to deliver translations quickly, they focus on the work that needs to be done. It is vital to easily recognise where the changes are in the original text and update these in translation.
An important additional benefit is that by using the same tooling, i.e. the Translate extension, the same skills are used for localisation of software and the translation of text, this makes it more easy for the Meta translator community and the translatewiki.net localisation community to work on the same projects and to share best practices.
Tooling
[edit ]In the past professional translators have refused to help us with translations. They want to use the tools they are familiar with and if not, they expect our tools to ensure that their time will not be wasted. For the localisation of software we support Gettext, a format understood by many professional tools.
Additional information about a text fragment
[edit ]Often a text is clear within a particular frame of reference. It can not be expected that our translators understand what is meant. When they ask for clarification, it is possible to document a message with some clarification. This is then used to modify the translation in such a way that the intent of the message stays the same, but is expressed in a way that makes sense for people reading in another language.
Keeping track of available work
[edit ]The Translate special pages will automatically show if there is translation work left to do.
How it works
[edit ]Any text of a moderate size consists of paragraphs, sentences. Typically a change in an existing text will happen in some, but not all parts; a paragraph can be added, deleted or the text can be modified. By recognising what has happened, it is possible to pinpoint what needs to be done. Consequently a text is fragmented in individual messages.
Work flow for translations
[edit ]- Once a text is tagged and marked for translation by a translation manager, the text becomes available for translation.
- A translator picks up the page either from the special page or from the link on the page that is to be translated.
- A text part ("unit") is translated and a next message can be selected when the translation is saved.
- The translation is marked as available and the translated parts will be available for view.
Guidelines for translations
[edit ]All translation systems on Meta are superseded by the Translate extension, in general, with some exceptions. The Translate special pages (Special:LanguageStats mostly) replace the current Translation requests page, which shouldn't be used any longer.
The Translate extension is quite flexible, but to a limit. It has to be used correctly, or it will impose improper burdens on translators. In general, the bigger are the translation units into which the page is split, the more is the translators' freedom; the smaller they are (as in default, automatic splitting) the more translators are forced to follow the original document structure without much freedom and the easier it is to track changes and ensure updates and consistency of translations. Translation administrators should prepare each page for translation correctly as needed: See the "How to prepare a page for translation" tutorial and the in-depth documentation.
- Essays and other community pages (also help?): Extremely free, at most one translation unit per section.
- Official policies and guidelines, legal documents, translation requests for publishing elsewhere: Standard Translate extension splitting to ensure consistency. [Remember to explain workflow and states.]
There's some overlap or another subcase among the two (between almost complete flexibility and total consistency).
Maintenance
[edit ]- All categories must be translated: the translation will be in a language code subpage, as e.g. in mw:Special:MyLanguage/Category:Help. The extension automatically produces links to other languages and allows to translate the title of the category (as well as the description), but the category listing will always show the page or category name (see bugzilla). All pages will automatically be put in a translated category without translator intervention via a template which takes the code from its subpage name (todo; there's a translatewiki:Template:Langcat but it's not very intuitive, while wm2012:Template:AddLanguageCategory is quite inefficient and needs the language list to be maintained manually).
- Translated versions of templates should be included as well (cf. translatewiki:Template:Localized). It's not clear whether to use simple subpages (as with {{draft}}) or an autotranslate system as on Commons, but some autotranslated templates exist already;[1] both systems allow to translate the template's content with the extension. LS-base templates such as {{essay}} are superseded and should probably be migrated, but it's not mandatory.
- Sidebar: Fully translated as explained on doc page about unstructured element translation, probably restricted to sysops anyway because opening to all users is too much. See documentation on Meta-Wiki’s sidebar.
Other
[edit ]- CentralNotice: currently not integrated at all with the extension, still needs manual input of translations. People are still using the old system based on {{cn translation status}} and a single translation request page (see also Fundraising 2011/Translation/Project report). This is currently the only easy way to recycle translation of old messages (combined with the banner-cloning feature of CentralNotice). Translate extension can be used for new translations, probably the best way is to put all strings for a (set of) CentralNotice in a single page, one subpage per language; the extension takes care of the workflow states which can be seen by the sysops on Special:MessageGroupStats.[2]
Process
[edit ]In general
[edit ]The translation system will continue to be managed by volunteers mainly, as it's always been. Technically, because page translation syntax can be a bit hard and some checks need to be done, the translation administrator flag is needed to enable translation of (any version of) a page. Meta administrators will be able to add (and remove) themselves to the group if they are willing to help other users or need it and they know what to do (because they've read the documentation and if possible tested it — Meta is not a playground and translators are not toys). Additionally, any user will be able to request it to local bureaucrats at WM:RFA. All details on Meta:Translation administrators .[3]
All users are able to add translation tags to a page and request its translation; a translation administrator has to pick it on Special:PageTranslation, check it and mark it for translation. Users can also request help on the usual WM:RFH page if they don't want to learn Translate syntax. There's currently no way to put translations in a higher priority, but this never worked anyway: if a translation is in priority, ask translation on translators-l or directly to translators.[4]
Migration
[edit ]- Main page: keep subpages and migrate (without most templates, based on old version).
- Archived translation requests: decategorise etc.
- wmf: wiki policies and most important pages: copy/import (with history) on Meta, translate and keep here (without bothering to export).
- Except board resolutions, votes and minutes and other stuff managed by the board directly, as the board is interested in using Translate directly on wiki.
- A list is being developed at Translation requests/WMF.
- Active translation requests for publishing elsewhere: migrate.
- All other Meta existing non-English pages: migrate.
- User:Nemo bis/Old translations (check also Category:Language link templates and Template:Other languages [1]): to be categorised etc.
- Move all translated pages under langcode subpages, leaving redirects.
- This will also serve to identify what's the actual content sitting around.
- A bot tags all source (English) pages for translation:
- the whole pages is marked for translation, except templates and categories automatically translated;
- the page is edited so that it creates only one translation unit (apart from the title): only one translate tag, all double newlines are removed.
- Pages are marked for translation and the subpages are overwritten with the English text.
- A bot (or an importer) uploads the old content of the translated pages in the (single) relevant translation unit in the Translations namespace.
- This needs to be done immediately because the previous step has hidden all the translated content: everything must be ready before the previous step.
- Ideally, at some point a bot also fetches the old translated pages titles from the redirects and creates the titles translations (translation unit 0).
- Old translations infrastructure.
- Translation requests (with all its translations) is redirected to Meta:Babylon , which is revamped and greatly simplified, including basically only some pointers to special pages, help and a few other things. Translation is updated/rewritten as a very basic help page for the new system (with Meta-specific info, cf [2]) and Translation FAQ (with all its translations) is redirected to it.
- Translation requests not using the new system (e.g. requests for translations which actually live on other wikis) stay only in the subcategories of Category:Translation requests, kept as an archive as well as Category:Translations by status subdirectories, which are soft-redirected to Special:MessageGroupStats (the same for Translations/Finalizing requests).
- "Translations/links/template" was transformed in a redirect to Special:LanguageStats.
- Category:Translations by language is kept but preferably populated with an automatic template.
- All translation requests templates are marked as deprecated. (Check also templates listed here.)
Notes
[edit ]- ↑ See commons:Commons:Localisation; could be improved by the usage of
{{UILANGCODE}}
instead of the {{int:lang}} hack to get the user's language.
Currently{{UILANGCODE}}
returns "en" on this page, either as a red link to a missing Template:UILANGCODE, or as the result of transition of that template containing the{{int:lang}}
hack still currently used in Template:LangSwitch and many auto translated templates, when this{{UILANGCODE}}
should be a native keyword extension of MediaWiki itself.
Many auto translated templates based on LangSwitch are easy to convert to use the new Translate extension: replace those LangSwitch invocations by translate tags around the default language, and move the existing translations in LangSwitch to the subpages per language. This conversion work (including the transfer of existing translations), could be assisted by a bot account, to be run by someone having the Translate privilege (otherwise these templates prepared using the "translate" tags will not work as long as there are not marked ready for translation). - ↑ This simplifies a lot for translators, who have a hard time understanding status templates and often make mistakes. The CentralNotice translation currently needs some more development on the administration end; Siebrand and Nikerabbit are going to talk about it, feedback appreciated.
- ↑ This won't basically changed anything compared to the previous system, which used to be managed by Transcom members and other experienced users (usually sysops), but it will make clearer who's working on translations.
- ↑ This won't basically change the old process, which was understood only by very few users. The new system is smoother and documented and has clearer roles and tasks.