Pages
Introduction #
WordPress is translated into many languages and all translations are powered by volunteer community members. If you would like to start translating WordPress, check WordPress In Your Language (and the resources cited there) to see if a translation of WordPress into your language already exists.
It is also possible that someone, or a team, is already working on translating WordPress into your language, but they haven’t finished yet. To find out, subscribe to the polyglots’ blog, introduce yourself, and ask if there’s anyone translating into your language. There is also a list of localization teams and localization teams currently forming, which you can check to see if a translation is in progress.
Qualifications #
If a WordPress translation in your language does not already exist or does not have someone working on it, you may want to volunteer to create a public translation of WordPress into your language. If so, here are the qualifications you will need:
- You need to be truly bilingual – fluent in both written English and the language(s) you will be translating into. Casual knowledge of either one will make translating difficult for you, or make the localization you create confusing to native speakers.
- You need to be familiar with PHP, as you will sometimes need to read through the WordPress code to figure out the best way to translate messages.
- You should be familiar with human language constructs: nouns, verbs, articles, etc., different types of each, and be able to identify variations of their contexts in English.
Tips For Good Translations #
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.
Locales #
A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil).
You can do a translation for any locale you wish, even other English locales such as Canadian English or Australian English, to adjust for regional spelling and idioms.
The default locale of WordPress is US English.
Localization Technology #
WordPress developers chose to use the GNU gettext localization framework to provide localization infrastructure to WordPress. gettext is a mature, widely-used framework for modular translation of software, and is the de facto standard for localization in the open source/free software realm.
gettext uses message-level translation – that is, every “message” displayed to users is translated individually, whether it be a paragraph or a single word. In WordPress, such “messages” are generated, translated, and used by the WordPress PHP files via two PHP functions. __() is used when the message is passed as an argument to another function; _e() is used to write the message directly to the page. More detail on these two functions:
__(‘message’)
Searches the localization module for the translation of ‘message’, and passes the translation to the PHP return statement. If no translation is found for ‘message’, it just returns ‘message’.
_e(‘message’)
Searches the localization module for the translation of ‘message’, and passes the translation to the PHP echo statement. If no translation is found for ‘message’, it just echoes ‘message’.
<?php $translated_text = __( $text, $domain ); ?>
The gettext framework takes care of most of WordPress. However, there are a few places in the WordPress distribution where gettext cannot be used – see Files For Direct Translation for more information on how to translate these spots.
andrewspittle 9:56 pm on August 5, 2012 Permalink | Log in to Reply
This is being pulled from the codex at:
https://codex.wordpress.org/Translating_WordPress
My goal was to break it up in to more digestible and focused sections that can be added to and refined over time.