Using GlotPress to Translate Content

GlotPress is a web-based translation management system (TMS) designed for translating software, such as WordPress themes and plugins. It is currently being used at https://translate.wordpress.org/ to translate:

  • WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
  • Plugins.
  • Themes.
  • Patterns.
  • MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress..
  • Apps.

Over the last few years, the documentation community has discussed and requested a platform to be able to translate the documentation. Some interesting posts:

With this first implementation, we are creating a tool using GlotPressGlotPress GlotPress is the translation management software that powers Translate.WordPress.org. More information is available at glotpress.org. as the backend to translate WordPress pages inline. The workflow is as follows:

  • Import the page content to GlotPress.
  • Start working on the translations in GlotPress.
  • Export the current translations to the translated page.

However, if the user prefers (and it is the recommended approach), they can do all the translations inline, without using the GlotPress interface, thanks to the inline functionality we added to GlotPress. The workflow for this method will be:

  • Import the page content to GlotPress.
  • Export the new page with contents in the original language and ready for translation.
  • Start translating inline.

Below are some screenshots that demonstrate the current functionality. Be aware that this is a demonstration of the feasibility of the “data flow”, not the final “user flow.” See the last section for what such a flow could look like.

Screenshots

Button to Import Page Content to GlotPress

The first action the user needs to perform is to import the page content. This action will create a new project in GlotPress.

Project in GlotPress

The previous action created a project inside GlotPress for the imported page, under the “Pages” project. Each page will have its own GlotPress project.

Imported stringsString A string is a translatable part of the software. A translation consists of a multitude of localized strings.

The user can see the imported strings without any translation. While the user can start translating strings here, the recommended approach is to use the inline translation feature.

DeployingDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. a translated page

Before starting the inline translation, the user needs to deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. the new page with the translations (or the originals if translations are not available for the current localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/).

Pages

Once you deploy the translated page, you are going to view both pages in the “Pages” section. In the next iteration, we need to add a “language mark” so the end-user will see this is the translated page (or the strings in the original language if they have not been translated).

Inline translation

Now, the user can go to the newly created page and start translating inline. These translations will be stored in the GlotPress tables, so the user won’t need to access the GlotPress frontend if they don’t want to.

If the user double-clicks on a red element, they will see a pop-up where they can add the translation or change any existing translation.

As the user translates the content, the background will change from red to green.

A Potential HelpHub Translation Flow

Based on the discoveries so far, we could see the following scenario in place. Note that the wp-admin screens from above will not be part of the workflow because these items are automated like shown below:

  • HelpHub would have its own GlotPress install residing in a subdirectory. GTEGeneral Translation Editor A General Translation Editor (often referred to as GTE) is a person, who has global access to validate strings on all projects for a specific locale. status would be reused from translate.wordpress.orgtranslate.wordpress.org The platform for contributing to the translation of WordPress core, themes and plugins., further PTEs can be appointed.
  • Updates to the English Documentation would lead to automatic updates of the GlotPress projects, making it thus easier to spot outdated documentation.
  • GlotPress and Inline Translation will be available for everyone with the known workflow where someone without enough permissions would submit a translation as waiting. Inline Translation will happen on a page which a post status set to private so that only logged-in users can see it.
  • Inline Translation will preview your own translations, even if they are not approved. Thus, you can translate a whole page and ensure that it reads well without having to wait for a review.
  • Translations would be automatically deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. (= set to publish) at a certain translation threshold.

Further Notes:

  • If the English text is updated, a translated old version will remain and show a note at the top. When a translator starts inline translating for this new page, a mixed-English-translated text will be written and the translator can translate it inline. When finished, the translated page will be deployed automatically.
  • The translator can see the amount of work necessary by looking in the language overview. See this mockup:
#glotpress, #inline, #local