With the recent upgrade, we have two useful new features for validators.
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.
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.
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.
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.
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.
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.
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.
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”.
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):
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.
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.
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.