Pll_the_languages

[Hyun Orth]

Ihope this is still relevant. For me the problem was that i didn't had any content for the languages, so I had to give an extra option to the pll_the_languages function for displaying the items even if they're empty -> array('hide_if_empty' => 0). It is set to 1 on default.

I use Polylang to have a german (default) an english version of the Website.

Int the header Section I included the language selector plus an additional graphic (a house) linked to home. Extract of the code in header.php:

Actually the menus work fine.

But I added an language selection graphic and a home graphic (house) in den Header.

Please see the section I mentioned in my first request (header.php).

The language selector works. But I don not know how to link the home graphic to the active language. Hope you can help ?

Thanks for the credentials. I checked your site. It seems both the language switcher and the home buttons are from the plugin itself (pll_the_languages function). I recommend you to contact Polylang plugin support.

In our first WordPress i18n article, we covered how to localize content with the Polylang plugin. In our second installment in this series, we looked at basic gettext with WordPress and how to start theme localization.

In this part, we'll round out our understanding of Wordpress theme localization with a bunch of recipes for accomplishing common tasks. By the end of this article, we'll have something to show our clients, Najla and Taha. In part 2, we started a custom localized theme for our clients' North African handmade crafts business, Handmade's Tale. By the end of this part, we'll actually have a deliverable to show Najla and Taha: a working localized theme. Here are the recipes we'll cover:

Note Since part 2, WordPress and some plugins have been updated. The updates are minor and point releases and shouldn't have any effect on our work in this series to date. However, do note the new version numbers if you're building along with us.

The Polylang plugin is handling a lot of the i18n work for us and, therefore, it deserves special mention. We'll be relying on the localization features that Polylang gives us as we build our theme. If you're not familiar with the basics of Polylang, you may want to check out part 1 of this series, where we cover the use of Polylang in detail.

Note If you're coding along and haven't completed all the code from part 2, you may want to clone and install the Github repo from part 2 and use it as your starting project to build on here. If you do so, make sure to go to Appearance > Menus in your admin panel and ensure that your menus are in the locations set in the theme. You may have to create new menus to see the locations.

This is all bread-and-better stuff for WordPress theme development. However, notice the use of the __() function above. __() takes a translatable string and a text domain and returns their translation in the current locale, if it's available. Let's build on top of this and add a loop.php file, since we're currently not showing any of our actual posts on the Newsfeed page

Note WordPress provides several _e() variants of its i18n functions, and they can be convenient when we want to echo out a translated string right away, which is most of the time. We cover many of WordPress' i18n functions in part 2.

Being the judicious WordPress developers we are, we should make this string translatable. And since we're pulling in our site name dynamically through WordPress' bloginfo(), we need a way to interpolate strings into our translations at runtime. This is commonly achieved with PHP's built-in sprintf() or printf() functions. Let's update our footer.php to use printf().

We use our good old __() function to register and return the translatable string "Copyright 2019 %s". Nothing new there. We then pass the translated string that __() gives us to printf() as a format string. printf() understands interpolation placeholders, like %s, and will replace them with the succeeding parameters it receives. In this case %s will be replaced with the localized name of our website, which we fetch using get_bloginfo('name').

All we have to do at this point is provide a translation for the string "Copyright 2019 %s" for each locale we support. We need to take care to place the %s interpolation placeholder appropriately in our translations.

This mouthful of code uses WordPress' _n() function to select between two translatable strings, one for singular and one for plural. _n() selects between the two forms based on its third integer parameter. The function's fourth parameter is the usual text domain which ensures the the translations are loaded from the correct PO file

While WordPress' _n() function seems to only be aware of two forms, singular and plural, some locales have more. Arabic, for example, can have 6 plural forms. Fortunately, the underlying gettext system that _n() uses has a way to define several plural forms. And _n() does actually support more than two forms, even though it appears not to.

This header defines each of Arabic's 6 plural forms, and a corresponding count integer for each. This kind of header is supplied for us automatically by Loco Translate plugin when we use it for gettext translations.

In fact, if we're using Loco Translate we can ignore all these syntactic details. Simply refreshing and saving our template and Arabic files yields an easy-to-use interface for supplying the 6 Arabic plural forms.

All we need to do is fill in each of the 6 forms and save the file. WordPress' _n() function will pick up the details from the PO file and present the appropriate form from the several we've provided.

Luckily, using the built-in WordPress functions the_date() and the_time() are enough to display the localized publish date and time for a post within The Loop. We can configure the per-locale format in the Polylang settings under Languages > String translations in the WordPress admin.

Note Did you notice our use of the_time() within the tag above? When we pass a format parameter to the_time() it overrides any formats we've set previously in the WordPress admin. And, when used with a format parameter, the_time() can be used to output both the date and the time.

The first parameter we supply to date_i18n() is a date format string. The second parameter is a Unix timestamp. date_i18n() will return the date and/or time (depending on our format) for the given locale if the locale specifies it. We can also use the locale we configured in the Polylang settings above if we want to.

There may be cases where we use the same word or phrase in two different places in our UI, and the word has a different meaning in each place. For example, we may use the word "More" for an infinite scroll button. We may also use "More" for a go-to-details button. In a given locale we may want to use different phrases for those two pieces of text. However, if we simply wrap the word in __(), our gettext system will try to avoid duplication and offer only one instance of the Word to translators.

To help solve this problem gettext gives us an additional context parameter that we can use when registering our translatable strings. WordPress taps into context through its x functions. Let's take a look.

Note Many WordPress i18n functions have context equivalents. For example, the plural i18n function, _n() has a context equivalent, _nx(). You can find all the WordPress i18n functions listed on the WordPress Codex.

When building internationalized WordPress sites we sometimes need to fork our code based on the current locale or language. WordPress has us covered there. The get_locale() function will return the current locale code.

Some locales are written left-to-right and others right-to-left. This often has an impact on our layouts. Arabic and Hebrew web pages, for example, may have a sidebar on the left instead of a Latin-centric right sidebar. To check the direction of the current layout, we can use WordPress' is_rtl() function.

In the above example, we display a font for use with our default locale (English in our case), and another font for Arabic. We rely on the HTML language attribute and CSS attribute selectors for our override. This technique pairs well with conditional, per-locale asset loading, which we'll go over in a moment.

After loading in our little CSS framework, Pure.css, we check to see if the Polylang pll_current_language() is available and sqwauk if it's not. This lets developers know about our dependencies right away.

Sometimes the language switchers that plugins like Polylang provide aren't enough, and we need something a little more customized to our needs. This isn't too difficult to accomplish with WordPress' widget system and the Polylang plugin.

The meat of our logic is in the overridden widget() method. Here we use Polylang's pll_the_languages() function with a raw flag to get an array of language names and URLs corresponding to all the translations available for the current page.

With WordPress, Polylang, and a little custom work, we've been able to put together a nice little website for our clients and learn quite a bit of WordPress i18n and gettext along the way. If you want to see this journey from its beginning, check out part 1 and part 2 of this series.

3a8082e126