RTL Support

[ryan]

Proposal RTL support through loading of locale-specific CSS. Using "fa" as an example locale, here's the gist.

• wp-includes/languages/fa.php contains some locale specific variables. $text_direction specifies the text direction, either 'ltr' or 'rtl'.

• fa.php, if it exists, is loaded into the $wp_locale singleton. The variables defined in fa.php are turned into instance variables of $wp_locale.

• When loading the front page, we check to see if the theme includes fa.css. If so, we load that css after style.css via a 'wp_head' hook.

• If fa.css does not exist and $wp_locale->text_direction is set to rtl and rtl.css is provided by the theme, load rtl.css.

• For the admin, if the text direction is rtl, load rtl.css from wp-admin. We would ship rtl.css as part of WP. It is loaded after wp-admin.css.

Eventually, fa.php could include other locale-specific settings such as the strings to use when constructing permalinks.

[ryan]

Support loading of locale specific CSS.

[majelbstoat]

This is a nice idea, but is it a core feature? Just so you know, Gengo already provides some RTL language support, which allows you to specify languages as RTL and then sets the direction on the posts themselves, but it's an area I'd like to improve on. Other plugins may also provide a way of doing this... A way of altering the direction for the sidebar, headers and admin would be good though.

Just a couple of questions:

Does get_locale() in locale.php::init() happen before or after the plugins_loaded() hook? I'm a bit fuzzy on the order of execution in 2.1.

Eventually, fa.php could include other locale-specific settings such as the strings to use when constructing permalinks.

What kind of strings are you talking about here? Category base? 'Archives' etc? This seems to be moving away from the gettext() method here, unless I misunderstand. I'm of the opinion that all the translated strings should be in one place in the .mo file.

[ryan]

It is being proposed as core, yes. I'll take a look at Gengo's RTL. If it just does direction for posts, it is working at a smaller level than this proposal. This proposal aims for full RTL themes.

The permalink strings are not well-suited to gettext because they have to be permanent. For existing blogs, suddenly having the permalinks change because they are not translated through gettext is bad. Plus, some plugins like to do some locale switching that could cause permalink strings to change back-and-forth. I have a proposal for handling i18n permalinks coming soon. Not breaking existing blogs requires some gymnastics.

The wp_locale singleton is instantiated after we load_default_textdomain(). load_default_textdomain() makes the first call to get_locale(). Both of these are called after plugins_loaded but before init.

[ryan]

Hey, nice plugin. If you've already been over some of this ground, do please make suggestions. The idea behind this proposal is to provide an easier means of supporting RTL languages at the theme level.

[mani_monaj]

Well, It's been about 18 months that I am working with WP in RTL. I tested Gengo, The ‎problem with RTL is more than just direction.. Alignment, Numbering and Possessions ‎are important too.‎

There is a great idea behind Gengo for providing Multi Language blog with Wordpress, ‎but it’s not sufficient for the look of the blog. I suggest following Ryan’s solution and ‎putting RTL support inside the core of Wordpress.‎

You know, RTLing wordpress is not just for themes, it’s also for admin area. When ‎translated strings loads, they must have correct CSS behind, to make admin area clean for ‎users.‎

These are essential features that wordpress needs to be fully RTL supported:‎

‎1) Providing additional CSS to make admin area RTL when needed. (Item no.5 in Ryan’s ‎gist)‎
‎2) Providing a framework for themers to put some standared RTL rules and make their ‎themes RTL ready. e.g.‎

p { direction: rtl; text-align: right}‎

‎(item no.4 in Ryan’s gist)‎

‎3) Providing a framework for themers to make their themes compatible with different ‎languages (item no.3 in Ryan’s gist)‎

[Sewar]

Why we use two different CSS files at the same time?

In ​WP-Arabic we was changed a lot parts in ​wp-admin.css (​Arabic version) to make it RTL and using Arabic fonts, i think the best way is:

<?php if ( ('rtl' == $wp_locale->text_direction) ) : ?> 
	<link rel="stylesheet" href="<?php echo get_option('siteurl') ?>/wp-admin/wp-admin-rtl.css?version=<?php bloginfo('version'); ?>" type="text/css" /> 
<?php else: ?>
	<link rel="stylesheet" href="<?php echo get_option('siteurl') ?>/wp-admin/wp-admin.css?version=<?php bloginfo('version'); ?>" type="text/css" /> 
<?php endif; ?>

the same thing for themes

And we need to change HTML tag:

<html xmlns="http://www.w3.org/1999/xhtml">

To:

<html xmlns="http://www.w3.org/1999/xhtml" dir="rtl" xml:lang="ar" lang="ar">

BTW, don't forget TinyMCE, there are variable "directionality" for RTL in initArray should be synced with RTL setting, and mce_buttons should be reversed.

[mani_monaj]

Well, I think seperate CSS file and load both of them if needed makes it easy to use CSS override ability.

It also simplies upgrading wordpress.

In ​wp-persian project, we are using a plugin to solve TinyMCE problem. in #1967 we added TinyMCE directionality to the core of wordpress, so it's simple to use that through a plugin.

[ryan]

I can't keep track of my svn views. I accidentally committed this in [4193]. Oh well, since it's in let's give it a try. If we hate it we can change or revert it.

[majelbstoat]

Well that's cool, it'll give me a chance to play around with it anyway. I'm toying with the idea of automatically generating the equivalent of fa.php when a user specifies a language as being RTL. That'd mean users wouldn't even have to find and install fa.php themselves, which would be beneficial I think. This could also be improved to work with permalinks at a later date too, if that became standard.

I also think that separate CSS files are the way to go - as long as rtl.css is added last, there'll be no problems.

As for i18n of permalinks, I've done some work on translating category permalinks - if that's going to be any help to you, let me know. Part of the problem I came up against was percent signs in permalinks not being re-encoded properly (#569) (this seriously affects permalinks for posts written in eastern languages) - the fix for that is there and ready for testing.

It's great to see WordPress embracing non-European languages - look forward to the developments...

[ryan]

With regard to permalinks, I think we need a little permalink_locale option in the DB in order to avoid breaking permalinks during an upgrade or when switching locales around. Here's the thinking:

• Store permalink strings in locale.php or use gettext somewhere in wp_rewrite but don't make the gettext strings "hot".

• During a new install, if we have permalink string translations for the current locale, set permalink_locale to the current locale. If the strings aren't translated (not in locale.php or not translated with gettext, depending on which way we go), leave permalink_locale empty.

• If doing an upgrade, leave permalink_locale blank unless PERMALINK_LOCALE is set in wp-confing.php. If PERMALINK_LOCALE is set and translations exist for the permalink strings, set permalink_locale to PERMALINK_LOCALE. We do this to avoid breaking existing permalinks. We don't want permalinks to suddenly change languages just because of an updated po file or locale.php.

• In the WP_Rewrite class, consult permalink_locale and use the translated permalink strings if it is set.

• Plugins can manipulate permalink_locale if they need to. We'll have a filter on it.

[ryan]

I think translating category permalinks is more within the scope of your plugin. WP doesn't natively support that type of multiple-locale functionality.

[ryan]

We can forego locale.php and just have a list of languages that are RTL embedded within core WP, but I kinda like leaving that to the translators. There are too many languages and allowing translators to control things like text_direction is more maintainable.

[mani_monaj]

I can't keep track of my svn views. I accidentally committed this in [4193]. Oh well, since it's in let's give it a try. If we hate it we can change or revert it.

You mean in [4194] ??

[mani_monaj]

We can forego locale.php and just have a list of languages that are RTL embedded within core WP, but I kinda like leaving that to the translators. There are too many languages and allowing translators to control things like text_direction is more maintainable.

I agree with this idea, let translators maintain things such directions. seperate php files for languages(eg fa_IR.php) makes future changes more easy to control.

Another issue, current Persian/Users currently use "post slugs" for pages and post, because Persian or Arabic in URIs are encoded. So I think we should seperate RTL issue and permalink translation issue.

Permalink translation is good for europian people who use encodings like Windows-1252.

[mani_monaj]

WP Admin RTL CSS (new)

[ryan]

If browsers are supporting unencoded Farsi and Arabic properly these days, maybe we can turn off the UTF-8 octet encoding across the board. We'll need some back-compat code to handle old URLs, but new ones can be left unencoded.

[ryan]

Regarding rtl.css, is it necessary to change the font like that? If so, is it generally necessary for all RTL languages or just for specific ones?

[mani_monaj]

Regarding rtl.css, is it necessary to change the font like that? If so, is it generally necessary for all RTL languages or just for specific ones?

90% of persian sites rather use Tahoma az default font. We always use tahoma az default font in ​Persian Wordpress project, as you see in ​this file from ​Wordpress Arabic project, We can see they(Arab Developers) use the same method.

So , I don't see any problems using this file.

[mani_monaj]

Actions and Filters for TinyMCE to add direction fixes and Directionality plugin and Buttons for RTL users

[ryan]

[4201]

[Ali_ix]

@Sewar
The first CSS file is the main and default style included.
The second one (ex: fa.css or rtl.css) will overrid some styles in the main CSS file that must be changed in order to have a good looking (not only RTLed) interface.

As you know it will reduce the code and avoid duplications.
And it is so easier too keep a 2KB CSS file updated during changes of admin (or themes) interface.

We also can apply this to Themes like SandBox by providing users with a rtl.css file.

@Ryan
persian and arabic characters smaller than 14px are not readable in most font families (like Times and Georgia in serif).
So we use Tahoma as default and common font face.
in larger font sizes and headings Serif fonts are fine.

[Sewar]

I respect your opinions in using separate CSS files, but there are problems in doing this. For example, user_info contain "left" property, if we add "right" property in RTL CSS file, the browser will apply both of these properties and user_info's width will be very long (body's width - (left + right)), and its contents will be in the right but we need them in the left.

Is there anyway to reset these properties to their default? setting them to 0 will fix some of them, adding "text-align: left;" will fix user_info, others may can't fixed or need hard coding, but we can fix all these bugs by using one CSS file only.

I have also add 3 varibales for Website, Documentation and Forums URLs in /wp-includes/languages/fa.php.

In dashboard the links list appears outside of the screen, you should browse to right to see it, i fieled fix this bug. Also, there are bug in DBX-Wrapper, see #????, in RTL there are more bugs about this, i will fix them after #???? fixed. (I can't find that ticket again :()

Also, i have fixed some bugs related to RTL, and some cleanup.

[ryan]

[4217] dds language and text_direction attributes to bloginfo and sets lang and dir attributes in the admin header's html tag.

[ryan]

I think we can handle the forum/doc urls via gettext. If there are any urls not marked for translation with gettext, let's patch that.

I'll look over the CSS changes.

[ryan]

[4218] adds language_attributes() template tag.

[Ali_ix]

@Sewar:
Yes, there is some problems in overriding some css styles. as you mentioned absolute positions are one of them.

Is there anyway to reset these properties to their default?

yes! you can overrid absolute positions (i hope). if the left value is assigned before, you can set it to "auto" and play with your right value then. as i tested in most cases and browsers this will reset(ignore) the left value (overrided by "auto") and applies the right one. (i have used this in the fa.css now and it works!).

[ryan]

So we can still do this by including rtl.css? Send me those patches. :-)

[Sewar]

Ali_ix: Thanks very much, it works fine.

ryan: Commit it :)

I have also patched wp-mce-help.php, i will patch wp-login.php, install.php and upgrade.php after #3123 fixed.

[ryan]

[4258]

[mani_monaj]

Well, the new changes seem to be great, WP needed such modifications and cleanups.

Ryan, If it is possible make core changes available in WP.com to see its effect. new RTL changes works fine in WP.com :)

[Ali_ix]

Thanks Ryan,
I hate inline styles ! :)

[Sewar]

Add support for RTL in install.php, upgrade.php and inline-uploading.php

[Sewar]

install.php, upgrade.php and readme.html uses inline CSS style, i moved it to wp-mini.css and add RTL support. Also, i added support for RTL in inline-uploading.php and cleans up its HTML code, so we can read it now!

[mani_monaj]

You are doing well Sewar, But could you please do something, Please create diff file from modified version through tools like Tortoise SVN, so we can view it online in better way, e.g. ​http://trac.wordpress.org/attachment/ticket/3136/tinymce-fixdir-action.diff

[westi]

mani_monaj those diff files look like they are created with a subversion aware diff tool. It's just trac deciding not to display them properly it seems to do that sometimes for no readily apparent reason.

[westi]

Setting back to ryan - didn't mean to change that.

[ryan]

[4259]

[Sewar]

mani_monaj: I'm using TortoiseSVN. It seems it's a bug in Trac as westi said, maybe because the patch file is big (+20 kB) or because it modifies a big blocks.

What we can also do here? except patching wp-login.php and themes (Default theme don't support multi language and no one use Classic theme).

[Sewar]

Add RTL support in wp-login.php and wp_die()

[ryan]

(In [4359]) RTL support for login sand wp_die() from Sewar. fixes #3136

[mani_monaj]

Well, These CSS files need some cleanups and revisions, I am working hard to fix some problems. Please let this ticket be opened till new changes get submitted.

[mdawaffe]

upload-rtl.css

[mdawaffe]

3136-upload-rtl.diff

I think this fixes the inline uploading CSS for RTL.

Sorry, mani_monaj, I didn't see you were working on this. Can you give this patch a look?

[Sewar]

mani_monaj: i have planned for cleanup wp-admin.css and seperate header, footer, editor and other parts, it will be easier to search for DIVs, etc. So, i will wait your patch.

mdawaffe: i have fixed upload-rtl.css, i will merge your patch with it and submit it.

[mani_monaj]

Sorry, mani_monaj, I didn't see you were working on this. Can you give this patch a look?

Well, I am working hard on this issue , RTLing Wordpress was one of major changes I was trying to convince WP-Team to do since one year ago. I should really thank all folks here who put time to make this dream true :)

As you know, this is a big step forward , so putting some time for cleanups is neccessary.

I am trying hard to submit patches or reporting problems as soon as possible.

[Sewar]

Some fixes for RTL CSS (including upload-rtl.css) added in #3217

[ryan]

The basic framework is in. Let's handle further issues in separate bugs. Resolving this one.