Skip to content

Tips for Good Translations

Pedro Mendonça edited this page Mar 11, 2015 · 3 revisions

As a translator, you want to make sure the language of the localized project is well-polished. Establishing and following translation rules might seem like a lot of extra work if you are just starting out. But in fact, it helps cut the translation team’s workload by reducing the need for correction and clarification. Here are some tips on making good translations:

Don’t include random links

The language files for WordPress projects should only contain links to pages found in wordpress.org domains (or other relevant project domains such as bbpress.org) or the translation community’s official documentation. If you need to link to a translated version of the original link, make sure it has a permanent home in one of those places.

Don’t translate literally, translate organically

Being bi- or multi-lingual, you undoubtedly know that the languages you speak have different structures, rhythms, tones, and inflections. Translated messages don’t need to be structured the same way as the English ones: take the ideas that are presented and come up with a message that expresses the same thing in a natural way for the target language. It’s the difference between creating an equal message and an equivalent message: don’t replicate, replace. Even with more structural items in messages, you have creative license to adapt and change if you feel it will be more logical for, or better adapted to, your target audience.

Try to keep the same level of formality (or informality)

Each message has a different level of formality or informality. Exactly what level of formality or informality to use for each message in your target language is something you’ll have to figure out on your own (or with your team), but WordPress messages (informational messages in particular) tend to have a politely informal tone in English. Try to accomplish the equivalent in the target language, within your cultural context.

Don’t use slang or audience-specific terms

Some amount of terminology is to be expected in a blog, but refrain from using colloquialisms that only the “in” crowd will get. If the uninitiated blogger were to install WordPress in your language, would they know what the term means? Words like pingback, trackback, and feed are exceptions to this rule; they’re terminology that are typically difficult to translate, and many translators choose to leave in English.

Read other software’s localizations in your language

If you get stuck or need direction, try reading through the translations of other popular software tools to get a feel for what terms are commonly used, how formality is addressed, etc. Of course, WordPress has its own tone and feel, so keep that in mind when you’re reading other localizations, but feel free to dig up UI terms and the like to maintain consistency with other software in your language.

Keep it consistent

Consistency is one of the most important characteristics of high quality translation. To maintain consistency throughout various WordPress projects, you can use glossary and style guide specific to your language.


Easy to understand.

WordPress.com translations should be easy to read and understand, even for non-technical users. Strive for friendliness, clarity, brevity, and active voice.

Make it your own.

The tone should reflect that of the original English writing. Focus on conveying the meaning and sentiment of the English, rather than providing a word-for-word translation. Some jokes and references might not work for all countries — in this case, you might want to omit or replace them with what will make sense for your locale. For example, we frequently use informal language like “Howdy,” a southern American English colloquial greeting. We use “Thanks for Flying with Us” in a few places, a casual and welcoming reference to how airlines often thank their passengers. The default WordPress install includes lyrics from “Hello Dolly,” a classic of American musical theater.

Keep it modern.

Ensure that you are up to date with the latest online and linguistic developments. Use modern terms and phrases and avoid anything that could be seen as old-fashioned.

Table of Contents

Brand, Upgrade, and Feature Names

WordPress: WordPress is always written as “WordPress” and should not be translated or transliterated. WordPress.com also remains WordPress.com (do not translate). WordPress and WordPress.com have different meanings.

WordPress.com theme names (e.g. Twenty Fourteen) are not to be translated.

Translating Dates

WordPress makes date display translatable using PHP date formats. You may come across date references when translating user interface strings. See below for examples of converted dates:

Y/m/d g:i:s A is converted to 2014/01/15 6:20:40 PM
j F, Y @ G:i:s is converted to 15 January, 2014 @ 18:20:40

When translating for your locale, move the parameters and add text as needed to confirm with the date format for your target language. Occasionally, replacing parameters (e.g. to 24-hour format with 12-hour format) will be appropriate for the locale.

Character Encoding

WordPress.com .po files use UTF-8 encoding. Using Unicode characters is acceptable, if the character is part of the target language (for example, “é” in “Sécurité”). For symbols (arrows, quotes, dashes), both are acceptable: either HTML symbol entities (such as ← or ”) or direct input of arrows, quotation marks etc from the locale-specific keyboard.

Translated .po files need to be in Unicode/UTF-8 format without BOM (need to be checked before importing back into WordPress).

HTML and Variables

HTML code/entities and variables (placeholders such as %1$s, %s, %d, etc.) can be moved around within a string but should not be translated or modified. Rare exceptions are noted in locale-specific translation guides as applicable.

From:


Translation Resources

https://en.support.wordpress.com/translation-resources/