The Language annual plan includes the audit of language tools as an initial step to plan improvements the different tools supported by the Language team. A list of proposed interventions is captured to identify key areas of work. You can check below the criteria followed, the areas selected, as well as other areas that have been considered out of the scope of the current initiative.
We are interested to hear your impressions about these plans. Please provide your feedback in the Language tools talk page. Let us know if there is any key piece of work for the selected areas, or new areas we should consider.
For this particular initiative we have considered the following criteria:
- Impact. Improvements provide a clear benefit to their direct users, or the larger community. Even if the impact is hard to measure in some cases, there should be a clear narrative on how the improvements in an area are helping to achieve our goals significantly better.
- Being realistic. Given the available resources, we need to pick areas where we can make progress. This work is planned for a period where the Language team will share its time with the work on version 2 of Content Translation which is a big project already.
- Focus on maintenance. Give priority to improving existing infrastructure over creating new tools. The initiative targets to reduce the work that has been accumulating for existing tools that are used every day.
Based on the criteria above, the proposed areas are captured below:
Improve the quality of translations for Translate extension
Translators that work providing content in their language need contextual information to provide high quality translations. Providing them better information and assistance will help them make better translations.
Translators produce better translations (and maybe faster as well). Users of different languages get a better experience when using our products.
- Improve (fix) translation memory
- Support creation and use of glossaries
- Better translation warnings and errors
Fluent import/export processes for Translate extension
Administrative efforts are required to set-up the translation process for a project. Creating the project, exporting the messages to be translated and import back the translations back into the software. These administrative processes requires effort that can be reduced.
Faster translation updates means: developer teams have to wait less to get their translations, translators see the impact of their work earlier (more motivated), and less effort required by admins. A platform where setting-up projects is easy, encourages creating more of them.
- Transparent and fast language addition process for translatewiki.net
- Transparent and fast project addition process for translatewiki.net
- Better export thresholds
- Support renames when importing message changes
- Automated exports from translatewiki.net
Improve processes for i18n support to be more fluent
Wikimedia has a robust process for managing localisations. It has evolved over time and requirements have changed. These processes can be simplified to avoid unnecessary duplication in language data and code.
Consolidating our different language data and code into libraries that are used in our projects makes the language experience consistent for developers and users. Maintenance overhead is reduced and there is less difference between backend (PHP) and frontend (JS).
- Consolidate language metadata into language-data and use it in MediaWiki core
- Better support for formal and informal variants
- Do something about TranslationNotifications
Other areas not in scope
These are some areas that have been considered but not included in the list of proposals based on the above criteria:
- Comfortable creation of multilingual content. We want content to be available in all languages, but making content multilingual makes it hard to work with it. Possible interventions: Visual page translation, Typed message parameters, and Translation of non-prose MediaWiki strings
- Considerations. Although it is an area of high potential impact, it also requires an amount of work that exceeds our available scope. Some of the interventions in this area can be proposed as future projects on its own.
- Translate new kinds of content. Our projects include more than just plain text. Rich context including diagrams or videos with subtitles require manual effort to be translated, which limits their availability in other languages. Possible interventions: Translate SVG files in Commons, Subtitle translation, Wikidata translation, and Machine translation of discussions.
- Considerations. Many of the interventions in this area require new tools or important changes on existing ones, which is not the focus of this maintenance effort.
- Making translators feel more like a community. People from projects providing content to be translated, and the translators making the translations, often don’t interact or coordinate with each other. A better sense of community and higher interaction can help to better use their efforts. Uncertainty what happens to translations after they are created can demotivate translators. Possible interventions: Activity reporting and engagement, Allow to solicit translations for specific subsets of messages, Relevant and reliable translation statistics, and Display “where_are_my_translations_deployed” information at translatewiki.net.
- Considerations. These interventions are relevant, but of a lower priority compared to improvements in the core processes.
- External use of our tools. Wikimedia has great tools to support multilingual content, making them available and easier to use for the rest of the world may encourage multilingual support around the web. Possible interventions: Librarization of MediaWiki i18n, Extract our PHP message parsing code to a library, Extensive and robust localisation file format coverage, and Continuous translation update service provided by translatewiki.net.
- Considerations. The improvements planned for Wikimedia projects will also benefit 3rd party users. A focus on external adoption is of a lower priority.