In an increasingly global world, the work of translators and interpreters serves an ever more important role in connecting people across the globe. Translators help create equality of access across a number of domains including: technology, medicine, education, and culture. Translation breaks down barriers and brings people together.
WordPress‘s goal is to empower people, no matter what language they speak or where they live, to create a website, a blog, or an app – a livelihood. Translation makes this possible. Without the hard work of our vibrant community of translators, WordPress would not be available in as many languages.
In honor of International Translation Day, we would like to take this opportunity to thank all the translators that have contributed translations to WordPress.com and the WordPress open source project. To our wonderful and diverse community of WordPress translators: we couldn’t do it without you!
* To contribute translations to WordPress.com or the WordPress open source project, please see some additional links below:
Happy new year! It’s time to look back at our translation community’s wonderful achievements during the past year and to thank everyone who contributed.
In 2018, 1,987 WordPress.com community volunteers contributed 66,343 strings in 104 languages, bringing the total number of translations to 247,800.
You all put in so much time and effort to make our service available to more users around the world. We know that it’s not always easy to translate English messages and labels to your language, so we want to thank you for your sharing your skills, creativity, and hard work with us and other users.
We are so happy to see both new faces and veteran contributors, and want to highlight the work of a few notable volunteers.
Parvez Qadir for leading the Saraiki translation project on WordPress.com
Dan Caragea for his help with reporting several bugs and missing parts while keeping Romanian translation up-to-date
Fredrik for bringing Swedish translation into higher active levels in the last year
Armuti for delighting Chuvash bloggers and site builders
The filter functionality in GlotPress has been a helpful way to search for strings in GlotPress. You can use filters to find out how a specific term is translated or to find a translation string you would like to improve. Filters give you the possibility to search through our entire repository of WordPress.com strings and translations. You can even find strings you have translated by filtering by a user.
While filters can be useful when translating, sometimes the filtered results are too large and don’t yield the results you were expecting. This would force you to scroll through several irrelevant strings to get to the right one.
We have now added the possibility to narrow down the scope of the search.
Under the “Term” field, you will see Term Scope options. Here you can choose whether you want to search for the term in the English Source (select Originals only) or the Translations (select Translations only). You can also search the context or string reference.
This can be used in many ways to improve your translation or validation workflow. For example, if you want to know how a feature name has been translated in your language, you can search for “originals only”. This will pull up every instance of the feature name. You can then check how it was translated across all strings in your language. If you want to change the translation of a term that has been translated inconsistently, you can filter for the “wrong” translation by “Translations only” and update the translation.
Have a look around! Try filtering for some terms or phrases. Maybe you will find other uses for the improved filters!
We have added a new feature to GlotPress to ease the handling of placeholders during translation!
Placeholder tags have long been a pain point for translators and validators in GlotPress. If a placeholder appears in the source string, the exact same placeholder must appear in the translation. To enter these into your translations, you would previously have to copy the placeholder from the source string and paste it into the correct place in the translation or manually enter the placeholder into the translation.
Now you can add placeholders while translating by simply clicking on the placeholder from list below the translation field. The placeholder will automatically be placed where your cursor is located.
Placeholders that are missing from the translation are shown in red. Once you insert the placeholder into the translation, it will turn green.
With this new feature, you no longer have to worry about typos in the placeholder text or errors copying partial tags! Additionally, you can easily edit fuzzy strings when only the placeholders have changed. We hope this new feature is helpful to you!
Another year, another gargantuan effort by the tireless WordPress polyglot community (all 2,941 of you!).
In 2017 community volunteers contributed 69,089 strings in 109 languages, bringing the total number of translations to 299,374 – a 34% increase since 2016.
Thanks to their work translating labels, tooltips, settings, editor buttons, headings, help text, themes and hundreds of other categories over more than 30 projects, there are now more happy WordPress.com users than ever.
All community volunteers deserve kudos/multiple hugs/pats on the back. Still, there are a few to whom we’d like to give a digital fist bump for being among our most active contributors this year.
armuti for giving 1.6 million Chuvash speakers the gift of WordPress.com
Ken Kenfor performing the Hong Kong/Taiwan Chinese double-whammy
వీవెన్, for the continuing contributions to Telugu, a language spoken by a whopping 75 million people!
Locales with the most activity
Here are the top 10 movers of 2017:
Chinese (Hong Kong)
The amount of translations and projects is forever climbing, and so is the number of WordPress users who, in their own languages, are delivering new ideas to the universe.
To those we didn’t mention – you know who you are – we bow to you. Language is the bridge to a better internet and better world, and your work has a direct and positive impact on the experience of millions of bloggers. Thank you for helping us make WordPress.com awesome for everyone.
We wish you all a fabulous 2018. Here’s to an even more successful year of polyglotism. 🙂
The community needs you
Would you like to contribute your linguistic knowledge to the biggest blogging community humankind has ever known? Great! Head over to translate.wordpress.com to find out how you can get started.
Current community translators can also request to become validators. Find out more in the FAQs.
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.