As announced here, the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team is focusing heavily on internationalization Internationalization (sometimes shortened to I18N , meaning “I - eighteen letters -N”) is the process of planning and implementing products and services so that they can easily be adapted to specific local languages and cultures, a process called localization. This is the process of making software translatable. Information about Internationalization for developers can be found in the Developer’s handbooks. and localization Localization (sometimes shortened to "l10n") is the process of adapting a product or service to a particular language, culture, and desired local "look-and-feel." in the development cycle for WordPress 3.4. This includes moving locale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/-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 Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. 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:
/*
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 HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. 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 ".
Further reading: ticket 19602, changeset 19795.
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 A string is a translatable part of the software. A translation consists of a multitude of localized strings.:
/* 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 -4 or 5.75. Timezones are better; try to avoid using offsets.
Further reading: ticket 19601, changeset 19785.
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.
Further reading: ticket 19601, changeset 19780.
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 Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/: 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 POT files are the template files for PO files. They will have all the translation strings left empty. A POT file is essentially an empty PO file without the translations, with just the original strings., ‘ltr’, with the context of ‘text direction’. RTL locales should translate this to ‘rtl’. (Updated February 7.)
Further reading: ticket 19600, post on wppolyglots.
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 A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1.)
Further reading: ticket 19599, post on wppolyglots.
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.
Translating wp-admin/setup-config.php
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 A string is a translatable part of the software. A translation consists of a multitude of localized 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 Multisite is a WordPress feature which allows users to create a network of sites on a single WordPress installation. Available since WordPress version 3.0, Multisite is a continuation of WPMU or WordPress Multiuser project. WordPress MultiUser project was discontinued and its features were included into WordPress core.https://codex.wordpress.org/Create_A_Network. 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 MO, or Machine Object is a binary data file that contains object data referenced by a program. It is typically used to translate program code, and may be loaded or imported into the GNU gettext program. This is the format used in a WordPress install. These files are normally located inside .../wp-content/languages/, 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.
Further reading: ticket 19852, post on wppolyglots.
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 The code name of the theme for the local WordPress sites (eg. bg.wordpress.org is a “Rosetta” site). All locale specific WordPress sites are referred to as “Rosetta sites.” The name was inspired from the ancient Rosetta Stone, which contained more or less the same text in three different languages. build process. If you were manually including these modified core files in your distribution on i18n.svn.wordpress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://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.
Further reading: ticket 19601, post on wppolyglots.
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 A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. options (URL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, feed URL, name) are already translatable in version 3.3, so please do not use any PHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php. code to modify the dashboard widgets.