As announced here, the core team is focusing heavily on internationalization and localization in the development cycle for WordPress 3.4. This includes moving locale-specific modifications into WordPress core, the development of language packs, and addressing long-standing bugs and enhancements.
This page is a list of what you as a translator needs to know as you prep for a 3.4 release. Topics will be added here as the relevant changes are committed to trunk.
Localizing commas, as a tag separator
Added February 7. A number of languages, such as Chinese, Arabic, and Burmese, do not use the standard comma (“,”). This causes some issues when it comes to adding or editing a post’s tags, using the tags meta box and quick/bulk edit. There is now a translatable comma (the context is “tag delimiter”), which will be used (in addition to the standard comma) to separate tags.
Further reading: ticket 7897.
Fields that should always be LTR
Added February 7. Fields that should always be LTR, such as passwords, code, login names, and URLs, are now forced to be LTR in core. See ticket 19598 for more.
Spellchecker language is now translatable
Added February 7. In TinyMCE, there is a spellchecker drop-down. The languages in this drop-down is now translatable, with a long translator’s comment to describe what to do:
[sourcecode language=”php” wraplines=”false”]
translators: These languages show up in the spellchecker drop-down menu, in the order specified, and with the first
language listed being the default language. They must be comma-separated and take the format of name=code, where name
is the language name (which you may internationalize), and code is a valid ISO 639 language code. Please test the
spellchecker with your values.
$mce_spellchecker_languages = __( ‘English=en,Danish=da,Dutch=nl,Finnish=fi,French=fr,German=de,Italian=it,Polish=pl,Portuguese=pt,Spanish=es,Swedish=sv’ );
It should be noted that most browsers have spellcheckers built-in, and Jetpack includes After the Deadline to override the whole thing, so I don’t know how much longer this spellchecker will be in core.
Further reading: ticket 19962.
Localize single quotes, apostrophes, and primes
Added January 31. For a while now, you’ve been able to localize double quotes, which WordPress normally turns into “curly/smart quotes.” In 3.4, you can also translate ‘single quotes’, primes such as 9″ (nine inches) and 9′ (nine feet), and apostrophes. When untranslated, obviously, an apostrophe is the same as a single quote, and primes are either a double quote or a single quote. And, when texturized, an apostrophe uses the same HTML entity (&8217;) as a closing single quote. You may have a desire to translate these, or there may be no need to. That’s fine. They were actually introduced for the Hebrew translation, which never wants curly quotes, and therefore they are able to translate these to ' and ".
Originally posted on January 29:
How to specify a default timezone
If you had wanted to specify a default timezone or GMT offset in previous versions of WordPress, you would need to hook into populate_options. See he_IL.php as an example.
Version 3.4 now includes this as a translatable string:
/* translators: default GMT offset or timezone string. Must be either a valid offset (-12 to 14)
or a valid timezone string (America/New_York). See http://us3.php.net/manual/en/timezones.php
for all timezone strings supported by PHP.
$offset_or_tz = _x( ‘0’, ‘default GMT offset or timezone string’ );
Here, you can specify a valid timezone, such as
Asia/Jerusalem, or a GMT offset, such as
5.75. Timezones are better; try to avoid using offsets.
Feed language (rss_language option)
If you wanted to specify a language other than ‘en’ for previous versions of WordPress, you would need to hook into populate_options. See he_IL.php as an example.
Version 3.4 now leverages the same code behind
language_attributes(), in the form of
bloginfo_rss('language') (this ends up using
get_locale()). Therefore, there is nothing you need to do any longer for rss_language.
Further reading: ticket 13440.
Specifying the start of the week
To specify a start of a week other than Monday, you no longer need to hook into populate_options. Version 3.4 now includes this as a translatable string:
/* translators: default start of the week. 0 = Sunday, 1 = Monday */
‘start_of_week’ => _x( ‘1’, ‘start of week’ ),
You can use 0–6 to specify a start of the week that is appropriate for your locale, with 0 being Sunday, 1 being Monday (the default, as it is ISO-8601 standard), etc.
Specifying that your language is right-to-left
Version 3.4 no longer requires
$text_direction = 'rtl'; to know that your language is RTL.
It now automatically detects RTL for the following locales: ar, ckb, fa_IR, he_IL, ug_CN, dv, fa_AF, ha, ps, uz_UZ, yi. If there is an omission or error here, please open a Trac ticket. There is a string in the main POT file, ‘ltr’, with the context of ‘text direction’. RTL locales should translate this to ‘rtl’. (Updated February 7.)
Specifying the default secret key for wp-config-sample.php
In previous versions of WordPress, if you translated ‘put your unique phrase here’ in wp-config-sample.php, you would need to assign the new placeholder to $wp_default_secret_key. In version 3.4, this is no longer necessary (and will no longer work). The placeholder you use will be appended to version.php (next to
$wp_local_package), and core will use this to ensure security as it had before. (This is not set up yet, but will be before Beta 1.)
Matching placeholders for DB constants in wp-config-sample.php and setup-config.php
Previously, if you translated the wp-config-sample.php placeholders (‘your_username_here’, etc.), you needed to update them in setup-config.php as well. This is no longer necessary: setup-config.php will replace whichever placeholder you specify.
Further reading: ticket 18180.
Through version 3.3, wp-admin/setup-config.php was a statically translated file. In version 3.4, we are able to load translations on this page, and since placeholders no longer need to be modified (see the previous point), this file should no longer be overridden in your distribution. The strings for this file are included in the POT.
Further reading: ticket 18180.
POT files are now split differently
In 3.0, we split multisite strings into a separate POT file. In 3.4, WordPress will now leverage three POT files: wordpress.pot, wordpress-admin.pot, and wordpress-admin-network.pot ($locale.mo, admin-$locale.mo, and admin-network-$locale.mo). As the names indicate, frontend and admin strings are now split, and the network admin is split from the admin. The files are hierarchical: wordpress.pot is for the frontend, the admin, and the network admin; wordpress-admin.pot is for the admin and network admin; and wordpress-admin-network.pot is only for the network admin. Because of this new split, there is no longer a separate multisite POT, as the savings are minimal.
WP_I18N_* hardcoded translations
WordPress has a number of strings that may be printed prior to translations being loaded, which required the strings to be hardcoded into individual files. We now have the ability to conditionally load a translation earlier than normal, in order to translate these strings normally. There are no more WP_I18N_* strings in WordPress. They will appear in the POT file as before.
Normally, these translations were inserted into core files during the Rosetta build process. If you were manually including these modified core files in your distribution on i18n.svn.wordpress.org, please remove them — they are no longer needed.
Further reading: ticket 18180.
Default Links (wp_links) are now available for translation
The names and URLs of default links (such as “Support Forums” and “WordPress Blog”) are now available for translation.
Dashboard Widgets are available for translation
At least one locale is replacing the core dashboard widgets for the WordPress Blog and the WordPress Planet with localized URLs. While this okay, these widget options (URL, feed URL, name) are already translatable in version 3.3, so please do not use any PHP code to modify the dashboard widgets.