Blog

New Features for Validators: Locale Glossary, Set as Fuzzy

With the recent upgrade, we have two useful new features for validators.

Locale Glossary

Building a robust glossary for your locale is crucial for a successful translation project. From now on, WordPress.com project validators can build a locale glossary shared across all translate.wordpress.com projects.

This means that translators no longer have to look up terms on the project glossary for WordPress.com while translating themes or any other projects.

russian-theme-translation-with-tooltip
Locale glossary term is shown while translating a theme

Validators can start building their locale glossary by importing an existing set of terms and translations*. For more information, check out this documentation.

* If you had a project glossary for the WordPress.com project, we’ve already migrated it to a locale glossary. You can find the new location on this list.

Set Current Translation as Fuzzy

Have you had a time when you wanted to change the status of an already approved translation from “Current” to “Fuzzy” while validating? Now validators can click the “Fuzzy” button on a questionable translation to mark it as not Current and come back to it later.

fuzzy-button

Until a new translation is approved and set as Current, Fuzzy items will become untranslated after a translation deploy**.

** Translation deploys happens irregularly for all projects except for the themes, which has scheduled deploys once a day after a completion threshold is met.

Special Thanks

These updates were made possible by everyone who contributed the release of GlotPress 2.3, the open source software behind translate.wordpress.com. Thank you!

translate.wordpress.com in 2016

Happy New Year!

2016 was a busy year on translate.wordpress.com, the translation platform of Automattic projects. For the first time, we are sharing some stats about the past year.

Numbers of Translators, Translations, and Locales

3,250 community volunteers translated 61,676 strings into 107 languages, resulting in 225,806 translations.

Most active users

These top 10 translators suggested the most translations across all projects.

  1. Dan Caragea (Romanian)
  2. Vijaya Madhavi (Hindi)
  3. Satnam S Virdi (Punjabi)
  4. Mariozo (Latvian)
  5. Manuela Silva (Portuguese/Portugal)
  6. Muhammad Farhan Danish (Urdu)
  7. Amreen (Urdu)
  8. justina33 (Lithuanian)
  9. gwgan (Welsh)
  10. cubells (Catalan)

top-wpcom-translators-2016.jpg

Most active locale teams

And congratulations to the locale teams that made the most progress this year.

  1. Romanian
  2. Hindi
  3. Urdu
  4. Latvian
  5. Punjabi
  6. Portuguese/Portugal
  7. Italian
  8. Icelandic
  9. French
  10. German

Number of active projects

translate.wordpress.com is not just for WordPress.com UI. Currently, there are 22 active projects (This number doesn’t include 399 WordPress.com themes).

We added 14 new WooCommerce-related projects this year.


We would like to thank everyone who helped us reach out to users around the world who speak languages other than English. Your effort makes it possible for more people to have a voice of their own.

We look forward to bringing you better support in translating WordPress.com and beyond this year!


Alex, Hew, Julian, Naoko, and Yoav of Team Global

Translating Almost Entire WordPress.com in Romanian: Story of Dan Caragea

For quite a while, either Japanese or Brazilian Portuguese had been the most translated locales of WordPress.com. Other locales closest to the 90% completion threshold were French (France), German, Spanish (Spain), and Swedish.

But today, 98% of WordPress.com is translated to Romanian with the highest percentage than any other locales.

wpcom-translation-status
WordPress.com translation project completion status

We were amazed to see the fast progress of the Romanian translation project and found out that Dan Caragea (dancarageact62) has been hard at work. On his own, he translated astonishing 23,613 strings this year. His contribution also includes WordPress.com themes and other projects.

I had a chance to ask Dan a few questions.

dan-caragea-romanian-translator
Dan Caragea, Romanian translation contributor

What made you decide to work on WordPress.com translation?

I noticed that Romanian WordPress.com translation project was stagnant for a while, even though it’s a platform very much used in my country. On the other hand, I realized that there are quite a few strings fetched directly from WordPress.com on my self-hosted WordPress site such as Jetpack related sections (I’m also one of Global Translation Editors of WordPress.org Romanian).

I began to translate on translate.wordpress.com but nobody validated my translations, so I asked to become a validator and started doing it alone.

Any tips you want to share with fellow translators?

No tips, just hard work, with a daily goal. It was maybe a personal bet: Romanian translation to have a share of over 90% by the end of year.

But to my joy, I reached the target earlier with a percentage that I never imagined when I started.

What do you use WordPress for?

Now I use a self-hosted WordPress for my blog.

dan-caragea-blog
Dan’s blog

We would like to congratulate Dan for achieving an impressive milestone. He inpired us by showing that dedicated hard work and setting small (daily) goals can make a big difference over time.


Would you like to help us translate WordPress.com into your language? Learn how to get started!

Context vs. Comment

While this post is intended for developers, it gives high level explanations of the concepts of contexts and comments which might be interesting for everyone who deals with translation of software.

Making original strings easier to translate

When creating code with translatable strings, developers might want to help translators by providing an explanation for the string.

Maybe they also know that translators are commonly presented just with the translatable string. They cannot see any adjacent code, and thus no variable names or other helpful pieces of surrounding text.

It turns out that there are two spots where additional information can be added to a string: via the second parameter of _x(), or with a /* translators: */ comment (or the context resp. comment parameter of translate()).

Let’s start with the takeaway message first: don’t use context, use a comment.

That sounds quite rigid but brings it to the point. To understand why, let’s look at what context actually is and when it’s used.

Context – oh, at that spot you need to have it translated differently? We can do that!

Practically speaking, every translation requires knowledge of the context of the original string, and translators will commonly ask for it (for example through a screenshot). You could call context the whereabouts of a string.

To correctly translate a string, it can make a big difference what’s shown next to it. Yet, we encourage our developers not to add context when they first create a string. Why?

It’s in the developers nature to reuse things, and we also want to foster reuse: if a string is used in new code that already has been translated before, then consequently there is less work for translators and that part of the new UI is already localized.

When the already translated string has a context, the new string needs to have the exact same context so that the translation can be reused.

So doesn’t the advice to not specify context commonly create problems with wrong translations in some places?

Surprisingly, it doesn’t happen too often. Most of the times the same string is used in different locations with the same meaning.

Occasionally–commonly true for one-word strings–English is less precise than other languages and it turns out that the use of a word in position A needs to be translated differently than when it’s used in position B.

comment-button-headline.png
Is “Comment” used in a headline or on a button?

That’s when a translator will ping the developer and show them the two places where the English original string needs two different translations. They’ll agree on a useful context for one (or sometimes both) of the strings which will in turn help the translators of other languages.

The agreed upon context will then be added using _x() (or the context parameter of translate()). Technically speaking, displaying a translation is done with a hash lookup, so both context and string are used for the lookup and therefore enables two separate translations.

As shown by the process above, a developer cannot judge whether the string will require more than one translation when it’s created. Consequently, a context should only be added upon request from translators, when they find that two (or more) separate translations are necessary.

The benefit of reusing more translations outweighs the extra effort to add context retrospectively.

Multilingual developers might already know that a string will need context when they create it, and we don’t want to prevent them from doing so. Just remember that we want to reuse existing translations, it is important to check if the string is already in our GlotPress with the right meaning.

In practice, simply leaving it without context is the easier route. The developer is trying to solve a different problem in the first place.

Comment – explain the original string for translators

We have spent a lot of time explaining context above but let’s come back to the start: developers want to help translators to find the right translation quickly!

The number one thing translators need explained is the variables that are used.

Remember that translators only see the translatable text. They don’t see variable names, they don’t see the code section or function name (for open source software there commonly is a code reference that can be used to look it up but translators cannot be expected to read code).

This is what such a comment looks like in code: (the comment must appear in the previous or actual line)

/* translators: %1$s: domain name, %2$s: date of renewal, %3$s: bundle name */

$body = __( 'The domain %1$s was last renewed on %2$s as part of %3$s.' );

Despite explaining variables being the most common use, any other explanation to translators is highly appreciated. Especially links to screenshots!

Comments don’t affect the lookup of strings. Multiple comments from different locations around the code will be concatenated, and might indicate to translators that a context might be needed to differenciate them.

Context – an example where it’s needed

This has all been very theoretical, so let’s conclude this post with a practical example of where context is required.

Let’s look at the string “Add New”. There are several occurances of it in the sidebar of the WordPress dashboard, where “Add New” can be a submenu item of “Posts” or “Media”.

add-new-wp-admin.png
“Add New” in two different submenus

For translating to Spanish it’s important to know what it actually is that’s going to be added because of the gender of the (imaginarily) following word.

So here, _x('Add New', 'post') and _x('Add New', 'add new media') have been used to allow translators to have different translations in Spanish and other languages (in the screenshot the grey box is the context):

add-new-spanish.png
Context allows for different translations of the same string

You can also see that context has been given to strings that do have the same translation in Spanish. That’s because other languages have differences in those cases.


Hopefully with this post we were able to provide you with a better understanding of the two methods for providing translators with additional information, feel free to ask further questions in the comments.

You might also want to take a look at the i18n quiz on developer.wordpress.com for more details around code and translation.

Welcome to WordPress.com Translation Resource Site

Since 2006, translate.wordpress.com has been serving its purpose as a collaborative translation platform for generous and enthusiastic volunteer translators.

Today, we are happy to share the brand-new section of this site with you. We’ve reorganized documentation, added this blog, and made it easier to find the information you need.

Screenshot of translate.wordpress.com homepage

Where did the translation projects go?

You can visit the “Project” section to view the page you used to see when you visited this domain. All of the functions of the translation tool stay the same, with the addition of footer links to the new translation resource pages.

Happy translating!