Sidebar region IDs and template variables are not semantic or RTL-friendly

I'm not sure if this is what should be expected..
The placement of blocks is controlled at "admin/build/blocks", so switching those automatic could confuse people (left becomes right, and right becomes left..)..

This is about personal favour, not about right or wrong.. Seriously a won't fix..

(I'm the original poster but I had to create a new account as the EZ@drupal.org.il stopped working)

Apparently you are not used to working with RTL applications...

When switching to RTL language, reversing the layout of pages is absolutely a matter of right and wrong, and certainly not a matter of personal preference.

Every application that (properly) supports RTL, switches the entire layout of the workspace, eg. the main menu aligns to the right. Similarly most web sites that serve RTL reading crowds have their menu on the right, etc.

See attached files for screen captures of Firefox in English (LTR) and Hebrew (RTL). I did not have to configure Firefox to change the placement of the main menu, order of input fields, and so on. Everything just switched automatically - as it should.

Not switching the layout will confuse all (RTL reading) users, and is a major flaw.

Not fixing this issue means that Drupal admins need to create separate RTL themes, as they used to do in older versions, so the efforts to implement RTL theme support in the core were a waste of time.

I strongly recommend to reconsider the "won't fix" decision.

Well, no response for two days, I'll change the status myself and see what happens...

I was/am invesigating this EZ.
But...

What is making it confusing (at least it is for me), is the fact that blocks in the "Left sidebar" are placed inside the "Right sidebar" and visa versa. We made the block placement configurable through "admin/build/block", which allows you RTL-guys to place the blocks inside the sidebar of choice.

Doing this automatically means that your blocks in a left region, appears in the right and the other way around. But still are placed in the region you did NOT specify. (You have to place a block into the left sidebar, to have it appear on the right??)

That's why I think it's confusing, but please try to convince me otherwise...

For now I'm marking this "Active (needs more info)"

Stefan,

First of all thank you for attending this issue.

I fully understand your confusion, as I've converted several systems to work properly in Hebrew and in particular fixing layout problems (eg. phpBB, Mantis bug tracker, Coppermine photo gallery). So here is...

RTL Layout Overview

.

The Basic Concept

In order to understand how RTL layout should work, the first step is to get rid of the misconception of Left and Right. Instead, I suggest the terms Home(-side) and End(-side). Left and Right convey absolute position, while Home and End depend on the writing direction.

So whatever is on the Home side in LTR layout should be on the Home side in RTL layout as well. However the Home side in LTR is on the left (writing from left to right) while in RTL the Home side is on the right (writing from right to left).

Suppose a "normal" (LTR) site designer wants some element to show always on the left. However if that same designer were a RTL language native, they'd want the element to be on the Right.

Caveats:

1. Absolute position by design:

In some cases, the site designer may want something to be positioned on the absolute left or right. As much as possible, there should be a provision to handle those cases.

This isn't always easy, because HTML and CSS do not have the (correct) concept of Home and End. Designers have to use different CSS for RTL pages, or generate HTML dynamically depending on the directionality of the page.

However if I have to choose whether to always switch layout vs. not switch at all - in my experience the correct behavior is to switch, as the "always force to left/right" situation is the exception rather than the rule.

2. Data/Text display and input:

Certain types of data should NOT be switched to the opposite direction under RTL layout, because they have inherent "natural" direction and alignment. (Please note the use of the term data rather than block or element.)

For example numbers and dates are all LTR characters (digits and separators) and always align to the right; URLs, email addresses, file system paths (usually) contain only LTR English characters and always align to the left.

When such data is displayed in a table or is presented for user input in RTL page/window, it should be forced to LTR directionality and to the proper Right or Left alignment (eg. number vs. URL).

[ Just for sake of completeness: When an isolated item of LTR data (eg. a number) is embedded in RTL text, the correct ordering and rendering is usually taken care of by the BiDi algorithm of the operating system or browser. However, it is good practice to surround such items with LTR markers, such as Unicode markers or <span dir="XXX">, in order to help the BiDi algorithm deal with ambiguous cases. ]

Finally...

Some time ago I started to write a full article about "RTL-ing web pages and applications", with detailed explanations and many examples. Due to lack of time I did not finish it, however the essence of the knowledge is what I wrote here.

I hope this helps. I'll be glad to answer any question.

Regards,

Eyal Zvi.

Sounds like a similar problem with semantic naming of classes/id's in CSS. Each element should describe its purpose, not how it is visually displayed on the page but block regions have no predefined purpose. That is up to the site operator.

I don't think there is a clean solution to this. Naming it left/right and letting it flip is awkward (even though it happens with our tables based themes). Home/end? That's just another concept that may only apply to a small minority of site and confuse the rest of us. I would leave this alone.

I think you missed the point entirely.

I do not suggest different naming conventions, but a different way to think about RTL layout. Once you figure out the correct layout, you can code it using the accepted conventions.

Of course RTL layout applies to a minority, but the point of RTL support is to help this minority, isn't it?

Anyway, fixing the RTL CSS will not affect any LTR site.

Eyal.

Maybe so.. But without a realistic solution, this will go nowhere. Do you have one?

Solution: Under RTL languages switch left and right positioning of blocks.

This is what RTL-native admins and users expect. You mentioned yourself that table-based themes flip sides in RTL. So it is a very realistic solution.

I'm not very familiar with the inner-workings of Drupal so I can't provide a patch.

For the future I suggest to replace absolute left and right positioning, with a more flexible (and correct) approach of language dependent left and right (eg. home/end) and on top of it add overrides for absolute positioning.

Eyal

Then this is a feature and should be "fixed" inside our theming system..

I've talked to a couple people about RTL layouts. And the expected behavior is, indeed, to flip the layout horizontally. For example, compare http://www.amnesty.org/en with http://www.amnesty.org/ar

So left and right sidebars would need to be semantically renamed. And core themes would need to flip their sidebars around for RTL languages. This would be a pretty straight-forward patch for me.

Over in #378948: Make left and right sidebars more RTL friendly (which I marked as a dupe of this issue), we briefly discussed some semantic replacement names. I'm going to repeat those here (and add commentary)

1. home sidebar, end sidebar
   Not a big fan of home and end. I recognize those are the keys you press to get to beginning/end of a line, but if you don't make that connection, the names seem somewhat randomly named.
2. first sidebar, last sidebar
   Used in Acquia Marina and on the Amnesty International site.
3. first sidebar, second sidebar
   Used in Tendu
4. primary sidebar, secondary sidebar
   This is possibly the best semantic choice. And one I am contemplating making in Zen: #375953: Change sidebar names to be RTL friendly My only concern is that we have lots of other things that are primary/secondary in the theme system: primary/secondary tabs, main/secondary links, main/secondary menus. Does this overload the terminology? If it does, my second choice is first/second, but I would also be fine with first/last.

I really, really like first/second - but primary/secondary would be okay for now. The reason I like first/second is because you can have first, second, third, fourth, etc. If you want to have more than two sidebars, you'd have primary, secondary, tertiary, quanternary?? Not as sustainable, in my mind...

I think Marina has them as sidebar_first/sidebar-first and sidebar_last/sidebar-last. Makes sense to me.

This is an interesting and important discussion.

I have no doubt that layout should/must be flipped in RTL - that's the case in 99.9% of the LTR/RTL sites i build.

As always - Tendu is the winner is my opinion. Tom has done it again... ;)

I vote for 'first' , 'second' , ...

I also agree that RTL layouts should be flipped. I've done it manually by customizing themes in Hebrew/English sites I've worked on. I don't care much for the terminology, as long as you can keep the same block settings for all languages, and don't need to have different one for RTL langauges and another for LTRs.

Haggai

@JohnAlbin -

I have to disagree.

First/Second - Imply numeric order, which may or may not correspond with the visual layout.

Primary/Secondary - Imply order of importance, which again does not necessarily corresponds to page layout.

I think that Home/End better convey the correct meaning.

EZ.

@EZ Actually, that was kind of my point. :-)

We want names that don't reflect layout, but instead represent something semantic about those regions. If a theme places both sidebar regions to the left or right of the content region, then home/end don't make sense anymore.

Out of interest I took a look a few popular RTL news sites, heres what I found:

http://www.aljazeera.net/Portal - rightArea (main content column), leftArea (left sidebar)
Once you get inside the site is switches to a tables layout with td (sidebars) naming like "tdRightServices".

http://eyoon.com/1/ - another tables layout, td (sidebar right) "rightmenu"

http://www.inn.co.il/ - there's a floating left sidebar, id="Left", in the main content its tables again and td class="HPLeft" and td class="HPRight".

http://dimona.org/ - wow, at last a pure CSS layout, again using classes like "left_mods" and "right_mods".

To be fair I looked at about a dozen others as well and pretty much nothing strayed from the left/right naming convention.

Ok, so that doesnt mean we should stick to left/right, but it was none-the-less interesting that actual RTL sites are using the same convention many LTR sites use.

Could someone please point to an external resource about this, I tried looking but didnt have much luck. From what I can tell in the real world its the left/right business as usual.

And yes, I get that we are really talking about sidebar flipping and how to support naming conventions that make sense, however that seems like a real edgecase (multilingual RTl / LTR sites).

Of the hundreds of RTL sites I have looked at over the past year or so while studying this, I found, I believe, one.

@jmburnz Thanks for the research. Its interesting to note that those sites are using left/right in their css/html. I really wish we could find existing sites that did this, but perhaps Drupal will lead this idea rather than follow.

The main issue for RTL sites is the block admin page, IMO. If we use "left sidebar" and that sidebar gets moved to the right for an RTL site (which it should), the locale module will translate that region name to "left sidebar" (i.e. its not going to translate the word "left" to "right" because that’s an incorrect language translation.) So, they'll see the "left sidebar" on the right side of their screen. #fail :-p

(Fixing tags after crosspost.)

I always considered the concept of using "left-whatever"/"right-whatever" in web development a bad Idea.

For the past several years a lot of my theming work is RTLing websites - on Drupal, .NET, WP and RoR; with or without tables, and always when a developer decides to use the words "left" or "right" in a class name, id or even a function it immediately creates confusion - should i rename it? should i change it on the server side or on the client side (the theme or the content)? what will happen when someone else will edit my code, will he be able to understand what i did?

With tables it's even worse - changing the page direction to RTL automatically changes the direction of the table, so now, no matter what you do, all the "left/right" declarations are meaningless.

Besides that, using "$left" and "$right" as names for the content of the sidebars has no semantic meaning. The sidebars are two of Drupal's defult regions, thats all, they don't have to be placed in a specific place, they don't even have to be sidebars. If I want my layout to have no sidebars, but still wnat to use Drupal default regions I have to "break" the semantics of my site or theme.

This is why in Tendu I decided to change the names to "first sidebar" and "second sidebar".
I use "second" and not "last" because, as someone already mentioned here, the second sidebar is not necessarily the last.
Same with "primary"/"secondary" - Semantically it has no meaning, what if i want to have my main menu on the other side? so now it's secondary? Who are you dear theme developer to decide for me what is primary and what is secondary?

If I could ditch the naming convention altogether I would have - Tendu has 9 regions and even I find the naming convention confusing sometimes (even though I am the one who named them...) but people are used to "header", "content" , "footer", "sidebar" etc. and Drupal use them as region names, so as I see it, forcing different names will only annoy and frustrate the users and developers (Aquia for example decided to use unique names for some its regions and sometimes I can't remember which is where even though I have a good knowledge of this theme, it can be frustrating sometimes).

So, after boring you with my thought - I think that using "first", "second" etc. is much better in general and specifically when BiDi is a consideration.
Another good solution could be an option for the theme developer to map (in the .info file for example) default region names to names that are meaningful in the context of his theme.

Tom B.

I cannot emphasize this enough - anything (from the options discussed) other then "first", "second", etc. makes absolutely no sense to me. and our designer hates it even more. it's confusing.

We use Tendu (by Tom) for pretty much every site. Its bi-directional consistency is by-far the best of all Drupal themes. It's easy to work with, and makes sense. about 50% of RTL sites we construct have a LTR version as well, which is an exact "flip" of the design. "first" stays first for the eye.

I vote (again) for "first" & "second".

IMO first, second does not make sense in layouts where these regions are not first or second in the layout. Remember, these are just regions I can place anywhere in the flow.

First and second may make sense in the rtl/ltr paradigm, but is semantically weak and no better than left/right in many contexts.

I like primary-sidebar, secondary-sidebar - I already use a version of this in Genesis, but for two regions in the horizontal axis - using:

secondary-content
main-content
teritary-content

I probably should have it like this:

secondary-content
primary-sidebar | primary-content | secondary-sidebar
teritary-content

@ jmburnz - that method confuses me a bit, with multiple 'primary' regions... I still think first, second, etc. is the way to go, since they are regions, they can be placed however a themer would like, logically. If not first, second, etc., then maybe "sidebar one, sidebar two, etc."

@geerlingguy, yeah, it is a bit wordy, I like sidebar-one, sidebar-two, makes more logical sense to me.

FWIW, using proper namespacing it should actually be:

content-secondary
sidebar-primary | content-primary | sidebar-secondary
content-teritary

FYI, pseudo CSS namespacing would be nice, something I failed to ram home in the tpl-refresh queue :/

Since the regions are abstracted from its purpose, I wouldn't mind the name itself being non-descript as it's been mentioned above. "sidebar_a/b/1/2", whatever.. From there, have the optional ability to re-label the regions from the admin ui so the site builder can actually describe their purpose. The default name being what's set from the .info file.

Just a thought.

@jmburnz:
I don't get how "primary" and "secondary" makes more sense then "first" and "second".

As I wrote in #19 - "primary" and "secondary" hints that everything in the secondary is less important then everything in the primary, or that secondary derives from the primary like in the menus and tabs in Drupal, which is not the case.

From all the alternatives, "first" and "second" is the less confiding solution - It is extensible and It has no hidden semantic meaning that can confuse the user(primary/secondary, first/last, right/left etc.), it just differs between the two regions, and hints about their HTML order.

Given this issue is against Garland I would suggest this is probably better discussed as a core issue? I have for a long time wanted to get rid of the whole concept of left/right - regions, body classes, class naming etc. Myabe we can leave Garland alone for now and tackle this in another issue?

Ok scratch that, me crazy busy to, anyway hunted around and found this issue #375953: Change sidebar names to be RTL friendly, food for thought?

@tom, yes, mostly right I agree, but thats my whole point, mostly everyone places content relative to its importance, for example often good stuff goes up the top and on the right (my thinks RTL that would be the left), whereas less important stuff gets shoved down the bottom or other less important position. They derive from the whole document, not from each other. The usage of primary and secondary on local tasks is wrong imo, it should be local-tasks-menu, local-tasks-submenu or something like that.

Really scratching to find some sort of best practice guidelines on this - any pointers?

@jmburnz:
btw - I've just noticed that Drupal.org structure itself proves my point about "primary" and "secondary". look at the page you are viewing now, only right sidebar = only 'second' or 'secondary' or 'last' or whatever.

Let's devide this to two -
The first issue is the sidebars variables that are $left and $right today.
The second is the default naming convention for their display names in admin/build/blocks.

I believe that the second issue is a non issue, every theme can name it whatever it wants, depending on the use this theme is doing with the sidebars - but of course that a good practice will be if the display name corresponds with the var name.

The variable names must change (again) (The names already changed from D5 to D6 if i remember correctly, from sidebar-left/right to just left/right), it is not intuitive in any way, regardless of RTL issues if creates.
I actually can't think of any good name (assuming the name 'sidebars' remains) that wasn't already discussed here.

Or we could just name them Alan and Bob :) 'sidebar-alan', 'sidebar-bob'.

Here's a rough-draft patch that renames all the regions to be sidebar-first and sidebar-second.

The last submitted patch failed testing.

Ok. All the tests should pass now. Let's see what the bot thinks.

To help reviewers, this is what the patch does.

1. Changes the description of the sidebars on admin/build/block from “Left sidebar” and “Right sidebar” to “First sidebar” and “Second sidebar”.
2. Changes $left and $right variables in the page.tpl to $sidebar_first and $sidebar_second.
3. Changes the body classes from .sidebar-left and .sidebar-right to .sidebar-first and .sidebar-second.
4. Changes the value of $layout variable in page.tpl from left/right/both to first/second/both.
5. Changes the page.tpl from using #sidebar-left and #sidebar-right CSS IDs to using #sidebar-first and #sidebar-second CSS IDs.
6. Does changes #2-5 for the default maintenance-page.tpl and for Garland's page.tpl and maintenance-page.tpl, as well.
7. The $page['#show_blocks'] variable used to control whether the left and right regions were rendered. It now controls the display of any region starting with sidebar_. So themes could extend this idea to any number of regions. For example, sidebar_third or sidebar_fourth.
8. Migrates any blocks in left or right regions to the first or second sidebar regions. This assumes that all themes will need to have their left and right regions renamed to sidebar_first and sidebar_second.
9. Fixes a ton of tests that relied on block placement in the left or right regions.

hmmmm! Can't we do the left and right thing dynamically. We know from usability testing that the left and right labels really help, while abstract things like primary and secondary menu's doesnt.

Bljhan, if you can forge a dynamic solution that works well I'd be most interested. I went down that route the first time I tackled RTL and ran into more problems than it solved, although I never really stuck at it.

I want to emphasize the point raised by Bojhan.

Hard-coded use of words left and right for sites whose content is LTR and RTL becomes a game of cognitive mind-screwing wherein you have to forget what left and right really mean as you write theme code for the site.

The use of "primary" and "secondary" or "first" and "second" is new, empty semantics.

A theme developer who wants to use semantic HTML ids will probably need to override page.tpl.php anyway. There's no universal sidebar naming semantics.

In RTL languages, the right side is still the right side. It's the content that appears in those regions that we want to switch around.

So why don't we just switch the values of $left and $right before they are passed into page.tpl.php when the language is RTL? This means Drupal needs to have an understanding of the relative lateral position of regions. The theme layer should be able to swap multiple pairs of regions that are in a lateral relationship like this. As far as I can tell, this is similar to the way JohnAlbin has solved the problem in the most recent patch except that it relies on "sidebar" as a naming convention, which I must say I am only 50% thrilled with.

If the theme info file defines some kind of array of paired bidirectional regions, they could be anything: sidebar_left, sidebar_right (default) or even header, footer if it came to that.

Block admin would need to use the logged in user's current language. A block allocated to a right region for a RTL user would be saved as being in the left region. The confusing LTR normalization would be limited to the database store or module hook_block_info implementations.

Block visibility may need new options: static (left is left whether RTL or LTR), bidirectional (default, meaning it jumps back and forth), RTL only, and LTR only depending on enabled languages. This would let things remain flexible. This setting would control whether a block is exceptional. (murky idea?)

@bangpound:

I totally disagree.

1st of all your statement "the right side is still the right side." is wrong.
It's not the content that changes sides, it's the entire page orientation and visibility.
Not only the sidebars flip, but the direction of the text, the left/right placement of elements in the header, every float-left/float-right element in the page etc.

2nd - The server side code should not care about directionality. It should only inform the client side about the language and load the right CSS files. Minimum intervention.

RTL/LTR is a *visual* property, therefore it should be solved with CSS.

@tombigel:

You've made me realize that swapping the content of left and right regions prevents you from being able to control the bidirectional orientation using purely CSS. You'd have to change your floats and aligns everywhere except for the sidebars that are defined as bidirectional.

However, I don't want to ignore the usability point which shows that users have an easier time with concrete labels like 'left' and 'right.' Obviously, they'd have a very hard time with 'left' and 'right' labels if the 'left' label is over on the 'right' in Arabic or Hebrew, which is what I meant when I said The right side is still the right side. But I don't think it's an improvement to replace one set of empty semantics with another: #sidebar_left is just as empty as #sidebar_first.

Is the usability concern for the block admin UI a separate issue from the possibility of changing the region IDs? The usability problem could still be solved by defining "bidirectional regions" in the theme's info file and using those labels in the appropriate order for the admin user's language. If a theme developer were not able to use only CSS to change the orientation of his page, some theme preprocess functions (or whatever we've got in D7... page alter, etc.) could be used that do what I describe... in contrib.

@bangpound:

I wrote it here in the thread somewhere before -

As I see it, the use of "left" and "right" everywhere in the code - in the HTML, CSS, JS or server-side is considered bad practice if your code will be used for LTR/RTL websites, because everything moves.(Unless of course it's something that will stay left/right no matter what)

The name "Sidebar" already hints about the placement of the region, so I don't think it's that misleading to remove the left/right and replace it with something more "generic".

@tombigel The research we did with menu's, shown that it was to misleading. I don't know what we can do to convince you.

Can't it just all be good in the code, and create some code to still display the right/left labels?

@bojhan: I see your concern but can we look at concrete use case: where and in what context the "Left/First" and "Right/Second" lables are exposed to the admin? admin/build/block ? In that page the labels are not that critical, we have dashed-border placeholders for each region and even when the region is called a vague "second", you will still see and perceive "it is in the right side".

The problem is more serious in cases when where is no such visual context as described above, like dropdown selections "pick a region", but those are rare cases, no? (only one I recall is views setting where to output dev information, but there might be others)

@kika - I would rather have people act on recall then recognition in this case - since your block page can become quite large.

Yes, on Blocks page it is not too much of a problem, but in all other places it will be. (We are adding it to the block creation page).

I don't see why we cant just reconize left and right with code, and output that for the labels.

I have a few mutually independent proposals.

1. We rename this issue. "Sidebar region names are not semantic or RTL-friendly" should be "Sidebar region IDs and template variables are not semantic or RTL-friendly." This is what everyone has been talking about since 25 February 2008 until dvessel and Bojhan raised the issue of the labels and usability.
2. We split the issue to create "Switch labels for some regions when language is RTL" where the usability issue can be solved. Solving that problem is different from renaming the IDs in templates and the names in info files. On that point, labels which use 'left' and 'right' are here to stay even for web sites which are bidirectional.
3. See Wikipedia articles on Chirality and Relative Direction and see that there are many different ways of saying left and right (left/right, verso/recto, port/starboard), but only sailors have found a way to describe direction of a vector relative to a point (wind and reading direction are vectors). Windward and leeward. #sidebar_windward? You guys would be so cool.

I really do not see how the issue can be fixed and closed without people agreeing to separate labels from names and IDs. Likewise, there's no familiar language adequate to describe what we want to describe and no universal semantics.

@bangpound: I like 1 and 2 of your proposal. #3 is a bit leeward of the vector I'd like to take for this issue. ;-)

I really like the idea of having an admin screen to re-label all the regions. That way sites could use a pre-made theme and just re-label (maybe even hide) regions so that they make sense for their use-case. But I'm having a hard time envisioning an admin screen that makes sense given the RTL issues and the extreme meta-ness of describing why you would want to re-label regions.

Unfortunately, thats a much more ambitious patch then I'm willing to commit to before the D7 code freeze. I have way too many things I want to get done first. :-(

However, even if someone did go ahead and create the above patch (I hope! I hope!), we would still need a way to determine the default RTL label for a region. Translators shouldn't have to learn everything about a particular theme to know that "left sidebar" should really be called "right sidebar" for a particular theme in the translated language. That's not the translators job.

So, how about, in addition to the usual .info region names, we could add some -rtl region labels? For example:

Then translators could just do their normal job and Drupal could swap out the correct label for RTL languages. Sound good?

JohnAlbin:

I was thinking of something like this:

The regions stay consistent with D6 info settings. The 'bidirectional_regions' define region pairs whose labels are swapped around.

(I'm staying outside any discussion of 'sidebar_first' vs. 'sidebar_left.')

This is how you could define additional regions...

Flipping labels and bidirectional regions defined in info sounds perfect to me, +1, like bidirectional_regions[] approach a lot, very sweet.

I've changed this issue's title to reflect a renewed focus on the names of the regions and the names of template variables.

A new issue has opened to improve usability of the block admin page on those themes (such as the default) who want to use 'left' and 'right' in their region names. #506776: Switch labels for some theme regions when language is RTL

Now that we've split the region label problem to a new issue, I've removed the Changes the description of the sidebars on admin/build/block from “Left sidebar” and “Right sidebar” to “First sidebar” and “Second sidebar” part of the patch. So the label for sidebar_first and sidebar_second remain “Left sidebar” and “Right sidebar”. See #506776: Switch labels for some theme regions when language is RTL about making the labels make sense for RTL languages, please. :-)

I've added a couple things to this new patch (items #9-11 below), so here's the list of things this patch does:

1. Changes $left and $right variables in the page.tpl to $sidebar_first and $sidebar_second.
2. Changes the body classes from .sidebar-left and .sidebar-right to .sidebar-first and .sidebar-second.
3. Changes the value of $layout variable in page.tpl from left/right/both to first/second/both.
4. Changes the page.tpl from using #sidebar-left and #sidebar-right CSS IDs to using #sidebar-first and #sidebar-second CSS IDs.
5. Does changes #1-4 for the default maintenance-page.tpl and for Garland's page.tpl and maintenance-page.tpl, as well.
6. The $page['#show_blocks'] variable used to control whether the left and right regions were rendered. It now controls the display of any region starting with sidebar_. So themes could extend this idea to any number of regions. For example, sidebar_third or sidebar_fourth.
7. Migrates any blocks in left or right regions to the first or second sidebar regions. This assumes that all themes will need to have their left and right regions renamed to sidebar_first and sidebar_second.
8. Fixes a ton of tests that relied on block placement in the left or right regions.
9. Modifies admin.css/admin-rtl.css so that div.admin .left and div.admin .right swap places when the language is RTL. This is the 2-column layout on the Drupal /admin page.
10. Modifies Garland’s style.css/style-rtl.css so that the left and right sidebars swap places when the language is RTL.
11. Modifies Stark’s layout.css/layout-rtl.css so that the left and right sidebars swap places when the language is RTL.

I've tested the patch. Poked it a lot, went through the templates, switch from Arabic to English, dropped blocks and moved them around. Nobody has spoken up against the ID name changes, so I take that to mean they're good. This is RTBC.

The last submitted patch failed testing.

JohnAlbin, I can fix your patch tonight. Rest easy.

Here's a new patch. The patch offsets were a bit off and the "fuzz" of the diff wasn't big enough to accommodate a full array value for the blocks in the default install profile. I wish I knew how to increase the fuzz!

NO code changes here. It's still RTBC.

The last submitted patch failed testing.

Reroll.

Doof.

The last submitted patch failed testing.

Re-rolled.

I spent about an hour with this patch, and read through the discussion which was very interesting/enlightening.

The case has been made to my satisfaction regarding the "first/second" machine-readable name of the regions. left/right is not semantic. home/end requires too specialized knowledge to "get it" for most average people (like me ;)). primary/secondary are wishy-washy words that have no meaning, and also overloaded given that we have primary/secondary navigation as well. First/Second are not only more clear in this regard, but also scalable out to third/fourth/...sixtieth... for extremely complex sidebars (though that sounds like more of a tragic MySpace horror story than an actual website).

The part which gives me serious pause of course is:

This obviously introduces a big themer WTF here, where the machine name of the region and the visible name of the region fail to match. But Bojhan and bangpound have made a pretty convincing statement that to site builders (which are a dramatically bigger pool of people than themers), "left" and "right" are very easy keywords to hone in on. Given the choice of introducing WTFs to two audiences, my vote is almost always for the more technical audience to take the hit, since they are better equipped to defend themselves with documentation, development tools, etc. And I think most themers will be generally aware of the semantic markup movement, so this terminology mis-match might even make sense to them (I hope :P).

Committed to HEAD. This needs to be documented in the D6->D7 theme upgrade docs.

Btw, on a completely other note, I *love* that we are prefixing these variables with "sidebar." $right and $left as variable names have always totally tripped me up.

I'm taking on the task of documenting the change in http://drupal.org/update/theme/6/7 as part of the first August documentation sprint! Edits currently underway.

Here's my documentation of the change: http://drupal.org/update/theme/6/7#sidebars-renamed

Documentation looks great! It just needs to be moved to the *bottom* of the document and then we're good to mark this fixed. :)

Richard took care of this, so marking fixed. Thanks so much! :D

I'm now getting the following php errors with the latest HEAD

Ok, clearing the cache produced the two above errors, and also the following two repeated a large number of times.

The errors then no longer appeared, but re-appeared every time I ran update.php or cleared the cache. Re-installing the db from scratch fixed it.

Someone who participated in this issue might want to help out with a quick RTBC over here, because Drupal is otherwise a bit broken right now:

#545356: Regression: Sidebars broken in install.php, update.php, and the expert profile

Thanks :)

Automatically closed -- issue fixed for 2 weeks with no activity.