Support » Requests and Feedback » WordPress Bug Affects the Middle East

  • I have two subdirectory sites sharing one WordPress installation using multisite, one site in a right-to-left language, the other in a left-to-right language. I’m not using any plugins; switching between the two sites is done by anchor text links. Although I specified the language of each of my multisite subdirectory sites in its own administration dashboard, the uploaded pages of the RTL site were incorrectly displayed LTR.

    In the support forum, I found that the same problem has been reported by many others, including those using plugins that allow two languages in the same site, on different pages. One of the support forum posts reported that a site primarily in a right-to-left language was displaying the pages in the left-to-right language incorrectly.

    Numerous support forum posts indicate that whenever a WordPress installation has pages in two directions, one of them is not displayed properly (unless coding changes are made to the theme or a plugin is used to make similar modifications). Some of these posts were written by users of a plugin that does not work with multisite, proving that the problem exists whether or not multisite is used.

    Using Firebug to see the HTML code that was actually uploaded for a page of the RTL language site, I found that the language was correctly detected. Despite this, when using WordPress 3.4.2, the HTML code said, right next to the correct language code, dir=”ltr”! (The dir= parameter disappeared from the uploaded HTML when I upgraded to WordPress 3.5, but the page was still displayed incorrectly LTR.)

    The value of dir=, as well as all directional-dependent formatting, should have been changed from the default LTR to RTL by rtl.css. I read in at least three Codex articles that WordPress automatically loads rtl.css if the language is right-to-left, and will not load rtl.css if the language is left-to-right. I have tried many themes that have rtl.css, including the default themes; all of them display the site in the right-to-left language incorrectly.

    None of the formatting instructions in rtl.css were carried out. All formatting of my RTL site was done exclusively by the LTR default file, style.css. Despite the information in the Codex articles, rtl.css was in fact NOT loaded automatically when appropriate.

    According to several posts, automatic loading of rtl-css apparently depends on a value stored in the domain’s WordPress folder, in wp-config.php, in the line that says ‘WPLANG’. Clearly, this value applies to the entire domain and the entire WordPress installation. One moderator of a support forum in a right-to-left language wrote that the language of the WordPress installation determines the direction of the site.

    This means that WordPress does not support automatic loading of rtl.css based on the page language, and (as I found) even usage of multisite does not enable automatic loading of rtl.css based on the subdomain or subdirectory site-language. Apparently, WordPress supports RTL languages out-of-the-box only for single-directional domains!

    Since many (if not most) online businesses in the Middle East require the use of languages in more than one direction, this situation provides insufficient support for RTL languages. I cordially request from the people who maintain WordPress: Please make the next release of WordPress auto-load rtl.css according to the PAGE language, not the WordPress installation language.

    In the meantime, how can webmasters with pages or sites in more than one direction get rtl.css to load only when the page language is RTL? A few methods have been used successfully to make bi-directional sites. I found the first three in the support forums, and I came up with a fourth.

    1) When the language is RTL, instead of having rtl.css (which contains only the direction-dependent items in style.css) loaded in addition to style.css, one webmaster prepared a css file for the RTL pages that has all formatting instructions in it, and used it instead of style.css and rtl.css. To do this, he made a copy of style.css, renaming this file style.XX.css, where XX is the language code of the RTL language. He changed all the corresponding items in this copy of style.css so they matched those in rtl.css, checking them off one by one; he left all the others as is. He made a second, unaltered copy of style.css, renaming it style.XX.css, where XX is the language code of the LTR language, and used this for the LTR language instead of style.css. (If you have more than one language in either direction you will need one file for each.) In the theme’s header.php, he found the link to style.css, and changed it to:

    <link rel='stylesheet' href='<?php echo bloginfo('template_url'); ?>/style_<?php bloginfo("language");?>.css' type='text/css' media='screen' />

    Note that this method does not ever link to “style.css”. This method seems problematic to me because any changes to a theme ought properly to be made in a child theme, whose only required file is style.css. I don’t know what will happen with a child theme if a style.css file exists but is never linked to. Worse, checking off all those changes one by one is error-prone and difficult to maintain if formatting updates are later made by the theme author.

    2) Another webmaster added the following code to load rtl.css on condition that the page about to be displayed was in the RTL language of his site. This code was added near the top of header.php just above the <head> line. (“XX” must be replaced with the language code; “YYY” must be replaced with the appropriate url of the theme file.) I’ve read that it is best not to hard-code the URL as he did, but rather use generic code that gets the right address automatically.

    <?php if(get_bloginfo('language')== 'XX' : ?>
        <link rel="stylesheet" href="YYY/rtl.css" type="text/css" media="screen" />
    <style type="text/css" media="screen">
    html { direction: rtl; }
    <?php endif; ?>

    3) Some people used plugins that handle bidirectional sites without any need for the user to make coding changes to the theme. Personally, I prefer to avoid plugins because they often have issues of slow performance, long-standing unresolved support posts, discontinued maintenance, etc. WPML reportedly handles multi-directional sites well, but it is no longer free. Polylang reportedly handles multidirectional sites if the option to display the text according to the visitor’s browser language is chosen, but Google says this is not a SEO-friendly option. (Note: multilingual plugins do not necessarily all support RTL.)

    I’m using a fourth method, which is both free and SEO-friendly, and has none of the issues associated with plug-ins.

    4) For optimal SEO, Google recommends that multi-lingual domains be organized with each language in its own subdomain or subdirectory site. (WordPress Multisite enables this.) Google also recommends using anchor text links instead of drop-down menus for navigation, and if you do this along with multisite, you can use the anchor text links to switch easily between your sites (languages) without a plugin. Multisite also enables you to use a different theme for each site, so it is a simple matter to use a parent theme for left-to-right sites, and a child theme for right-to-left ones. You need only one file in the child theme, the required style.css. After from the required line that imports the parent theme’s style.css, you need only one more line of code to import rtl.css. (I used bouquet, but any theme with rtl.css will do.)

    Theme Name:     Bouquet RTL
    Description:    child theme for RTL subdirectory of bi-directional domain
    Author:         CKatzman
    Template:       bouquet
    @import url("../bouquet/style.css");
    @import url("../bouquet/rtl.css");

    Very Important Note for those who have installed WordPress in a right-to-left language: to make a bi-directional website, no matter which method you choose, you must also comment out or erase the WPLANG line out of wp-config.php in your domain’s WordPress folder. If this is not done, WordPress will auto-load rtl.css even for your LTR pages!

  • The topic ‘WordPress Bug Affects the Middle East’ is closed to new replies.