Hot answers tagged translation
11
By far the best (easiest) way is to use the locale filter (inside get_locale()).
First set up a quick function for retrieving a different language to use on the locale filter.
/**
* A function returns with returns the user's selectd locale, if stored.
*/
function wpse35622_get_new_locale($locale=false){
$new_locale = ...
11
Indeed, wp_localize_script() is simple, it just adds quotes around the values and escapes the content, expecting all of them to be strings.
However, there is the l10n_print_after key of the array, which will be printed without any interference at all. It can be used to execute arbitrary code after the strings are passed. You can use it to pass your extra ...
11
1. Write with localization in mind
Don't use echo or print() to produce text output, instead use the WordPress functions __() and _e():
/** Not localization friendly */
echo "Welcome to my plugin";
// OR
print("Welcome to my plugin");
/** Localization friendly */
_e('Welcome to my plugin', 'my-plugin');
// OR
$my_text = __('Welcome to my plugin', ...
7
I wouldn't try to localize your slugs. Instead, why not give your users the option to change them by adding another field to the permalink settings page?
Hook into load-options-permalink.php and set up some things to catch the $_POST data to save your slug. Also add a settings field to the page.
<?php
add_action( 'load-options-permalink.php', ...
7
You can do the following:
Get the the language pack (e.g. de_DE.mo) from wordpress.org. If the language pack isn't available as a standalone download, you could also use the .mo file which is bundled in the WordPress ZIP-file for your language. Located under wp-content/languages.
Move the .mo file to wp-content/languages/ of your default (english) ...
6
Step 1
Open your file in PoEdit.
Step 2
Go to "Catalogue" » "Settings"
Step 3
Fill in "Language" and "Country" 1).
Step 4
Fill "Pluralform" (last field).
// For 2 plural forms
nplurals=2; plural=n != 1;
// For 3 plural forms (for e.g. russian), use:
nplurals=3; plural=(n%10==1 && n%100!=11) ? 0 : ((n%10>=2 && ...
6
The second part is not required, it just loads a PHP file with language specific functions.
Examples
In some countries/regions/religions it is not allowed to use capital letters in a word for anything else than the name of some god. In these cases you probably want to remove the Wordpress to WordPress filter.
Some languages (Chinese) do not use spaces (in ...
6
In this case, 'themify' is the defined textdomain for the Theme, used to make the Theme translatable. (Codex reference: load_theme_textdomain()).
Making a Theme translation-ready requires a few steps.
Define the Theme's textdomain:
load_theme_textdomain( 'themify', TEMPLATEPATH.'/languages' );
Define translatable strings in the template.
This is done ...
5
_x() let's you add a context to your strings. This is useful when you are using the same string in different places. This string may need different translations depending on the language.
Your example would be :
echo 'a1 in context 1 ' . _x('a1', 'context1', 'mydomain');
echo 'a1 in context 2 ' . _x('a1', 'context2', 'mydomain');
There are more examples ...
5
Use the filter 'mce_external_languages'. From wp-includes/class-wp-editor.php:
The following filter loads external language files for TinyMCE plugins.
It takes an associative array 'plugin_name' => 'path', where path is the
include path to the file. The language file should follow the same format as
/tinymce/langs/wp-langs.php and ...
5
You should move the po- and mo-file with the translation of your plugin outside your plugin's directory. Whenever you update your plugin, your plugin files are replaced causing any file that is not part of the default plugin package to be deleted. (If you are translating your own plugin, you could as well add the translation files directly to your plugin ...
5
In wp-includes/l10n.php you will find the function get_locale(). It offers a filter; you can set the language and ignore the constant:
function get_locale() {
global $locale;
if ( isset( $locale ) )
return apply_filters( 'locale', $locale );
// WPLANG is defined in wp-config.
if ( defined( 'WPLANG' ) )
$locale = WPLANG;
...
5
The Editor
There are others, but this is most used: Poedit, a cross-platform gettext catalogs (.po files) editor.
The Formats
.mo stands for Machine Object
-- compiled export of the .po file which is used by WordPress
.po stands for Portable Object
-- editable text file with the translations strings
-- based on the master .pot file, using Update from POT ...
5
You can get a list of available languages with get_available_languages( $dir ). It returns an array with all .mo files where the names does not start with 'continents-cities', 'ms-' or admin-.
To get a readable name for the file use format_code_lang( $code ).
If you scan a directory for language files and get an array like array( 'de_DE', 'tr_TR' ) this ...
5
First, read this Codex page about translating WordPress.
You have to create a language file to put into your language directory, do this by following the next steps:
I assume you want to use poedit since you talk about a .po file
download poedit
File > new catalog
In the first tab, fill in the fields, the most important ones are
Language, in your case: ...
4
Regardless if you go the PHP or jQuery route, I suggest you set up your filters or enqueue your Javascript in the admin_head-post[-new].php or admin_print_scripts-post[-new].php hook. There you can be sure that the global variable $post_type is set, and can check whether it is slide. Since the post thumbnail code is called after these hooks, you can set up ...
4
the_search_query() echoes itself, so by putting it into another echo function (what _e() is) you'll get result as in second example.
It isn't recommended to use variables or function inside l18n functions, because they can't be translated, for more information see Otto's: Internationalization: You’re probably doing it wrong.
So you should use code like ...
4
The list is available in $GLOBALS['l10n'][ $text_domain ].
To get the looong list of translatable WordPress strings just use:
print '<pre>' . htmlspecialchars( print_r( $GLOBALS['l10n']['default'], TRUE ) ) . '</pre>';
Do not use these strings in your theme or plugin.
They are internal, de facto private. They can change any time, even in ...
4
Use the fourth parameter for get_post_time():
$time = get_post_time(
'F j, Y', // format
TRUE, // GMT
get_the_ID(), // Post ID
TRUE // translate, use date_i18n()
);
get_post_time() calls mysql2date() internally, and it passes the $translate argument through. In mysql2date() we find this:
if ( $translate )
...
3
For people that come here looking for a more detailed explanation about the text domain issue instead of just "use a text domain". Here's how it works.
Firstly, you have to tell WordPress where the language files should be put in your theme, and what the 'theme slug' is (a unique identifier for your theme) like so:
add_action('after_setup_theme', ...
3
If you know that you or the client will NEVER need to be translated there is no need to replace all the strings within your theme with gettext.
Regarding the performance issue I found a benchmark comparing the 3 gettex methods. It also compared using the default local vs a different local and the differences were negligible which leads me to the conclusion ...
3
You both have the right idea, but you'll actually need both fitlers, one to catch the button text, another to catch the localised text, so a combination of the two.
This works..
class MyClass {
function __construct() {
add_action('admin_head-post.php', array ( $this, 'load_gettext_filters' ), 1 );
...
3
First, you have nasty typo in __contsruct. :)
Second, your hook timing is wrong. Related WP JavaScript is localized via postL10n object (you can see it echoed in page's source), that gets put together on init hook - way earlier then admin_head and your filter is not in place yet.
From quick test this should do it:
add_action( 'init', array ( &$this, ...
3
Welcome to WPSE Peter,
The second argument is a translation domain. This is essentially where the translation for the first argument can be found. By default it checks the WordPress language folder - but if you are creating a custom theme or plug-in,
you cannot rely on the translation for that string to be there (after all the WordPress language folders ...
3
The key is to use %s placeholders in combination with the sprintf or printf function.
printf(__('Search for “%s”', 'textdomain'), esc_html(get_search_query());
http://php.net/sprintf
Also note that the_search_query() outputs its result directly, you need get_search_query() which returns the result.
3
The translation strings not only get parsed during rendering (output on screen/in browser), but also by the GNU gettext parser. This one is not a PHP parser, so it can't fetch variables. This is the only part of a Theme or a Plugin, where you need to repeat yourself and add the plain string to every translation/gettext function call.
// Wrong:
__( 'External ...
2
I came up with a function that does the job for now :
/**
* Creates a translation of a post (to be used with WPML)
*
* @param int $post_id The ID of the post to be translated.
* @param string $post_type The post type of the post to be transaled (ie. 'post', 'page', 'custom type', etc.).
* @param string $lang The language of the translated post (ie ...
2
Use the CS Localization plugin and generate the po/mo files, thats all. Save the file also in the repo of git and ready. The performance of the theme is not so high, if you have the strings inside the php-files, but only so it is possible to create different languages for the themes. mo/po files is also ascii files and its give no problems with git or WP.
2
I am doing exactly that in a theme we are developing. It is available in 5 distinct languages, and each language has a translated set of categories. The first component of the URL in the theme is parsed to determine which language is used, in country-language format:
/uk-en
/fr-fr
/it-it
And then translated categories are parsed as further components of ...
2
I would recommend not making slugs translatable.
Translation is for user-facing site content. Slugs are used internally, and are only marginally "public-facing" via URL rewrites - and URLs should not be translatable, either.
So: leave your slugs alone, as you define them. Only make translatable strings that are intended for public consumption.
Only top voted, non community-wiki answers of a minimum length are eligible
