Default sidebar region labels are confusing (wrong) for RTL languages

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.

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.

@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.

@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.

@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:

regions[sidebar_first]      = left sidebar
regions[sidebar_first-rtl]  = right sidebar
regions[sidebar_second]     = right sidebar
regions[sidebar_second-rtl] = left sidebar
regions[content]            = content
regions[header]             = header
regions[footer]             = footer

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

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

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.

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:

-        'left' => 'Left sidebar',
-        'right' => 'Right sidebar',
+        'sidebar_first' => 'Left sidebar',
+        'sidebar_second' => 'Right sidebar',

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

* Notice: Undefined variable: sidebar_first in include() (line 41 of /Applications/MAMP/htdocs/drupalhead/themes/garland/page.tpl.php).
* Notice: Undefined variable: sidebar_second in include() (line 64 of /Applications/MAMP/htdocs/drupalhead/themes/garland/page.tpl.php).

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

 * Notice: Undefined index: filectime in _registry_rebuild() (line 71 of /Applications/MAMP/htdocs/drupalhead/includes/registry.inc).
 * Notice: Undefined index: filemtime in _registry_rebuild() (line 72 of /Applications/MAMP/htdocs/drupalhead/includes/registry.inc).

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 :)

I just had that "big themer WTF" moment webchick was refering to in #56, this is just wrong, the whole point of this issue is that $sidebar_first is not always going to be on the left - as on every hebrew/arabic website.
Just take a look at the English VS. the Hebrew versions of Wikipedia, is that sidebar - Left, Right or just First ?
Bottom line is that ATM we have blocks placed on the right sidebar showing up on the left for every Arabic/Hebrew site-builder, that looks more like a bug to me than a feature request.
So here's my little patch :

Also Zen and Bratik are using the terms first/ second sidebar.

> my vote is almost always for the more technical audience to take the hit

Maybe we can make the description longer e.g. sidebar_first' => 'First sidebar (Left sidebar on LTR themes)', - to satisfy all audiences?

The way it exists today is inconsistent - on one place the term "first" is used, and on another "left". Promoting to critical.

I think I'll take it a step forward and make it a bug report as displaying the left sidebar on the right and vice-versa (as in every RTL site) sure seems like a bug to me.

I don't think this is critical, its not breaking anything. You can override this in your info file and its well documented. Whether this is a bug or not is up for debate.

How is it not broke if Left is on the right and Right is on the left?
Overrides is irrelevant here, this is Drupal core.

I agree with yhager on this one... We went over this extensively in the .tpl.php refreshes, and I thought we had worked out the problem there, but apparently we still have a little more to go...

Good reading (point vs. counterpoint) in #16 and #17 above. But I think, as far as a themer's perspective, right and left are completely inadequate (regardless of what you think about language rtl/ltr support). First and last are soooo much more meaningful, semantically.

[Edit: Also, having 'right and left' can be a point of contention for themers who are just starting with Drupal... they might be inclined to think Drupal only supports a right and left sidebar—as I did, when I was starting out, and hadn't studied regions at all. R/L needs to die.]

I would like to understand what documentation Jeff is referring to in #69, AFAIK the only thing the documentation says is that $left and $right are out and $sidebar_first and $sidebar_second are in.

I haven't been following this issue very closely, but as far as I can tell the discussion of human-readable labels was intentionally moved to #506776: Switch labels for some theme regions when language is RTL, so I'm not sure why this is being reopened?

However, if we're looking for a quick (but not perfect) fix in Drupal 7, I am wondering if we couldn't just use the new localization context feature (http://drupal.org/node/224333#locale_context) to deal with this. If we ensure that when we are translating theme region labels we always pass along an appropriate context, for example:

t('Left sidebar', array(), array('context' => 'Theme region'))

then that should at least give translators some ability to help with this - a Hebrew/Arabic/etc translator would be able to ensure that in this particular case, "Left sidebar" is translated to mean "Right sidebar" instead (without messing up other translations of the same phrase in other situations where switching left/right would not be appropriate).

That issue is not going to be fixed in D7 and the patch committed here causes the confusion, that is why I reopened this issue.
A quick (and almost perfect) fix in Drupal 7 will be to finally get rid of the restrictive (and sometimes buggy) concept of Left/Right.
I don't understand why anyone will want so bad to keep them that we should create this first/left/second/right dualism (quadrolism ?)

What I meant by documentation is that you can change things in the info file, that is well documented.

I actually agree with the issue in most parts, however it was discussed at length quite some time ago and there was an issue posted to solve the problems, but it got no feedback: #506776: Switch labels for some theme regions when language is RTL

I think if you really have an issue go work on that one, get it cracking and try to get it in. I fully agree with Webchick that left and right are keywords users can hone in on, I see this all the time with the use of First and Last and my clients being momentarily stuck having to think which is which - in my themes I have to use First and Last (now First and Second in D7) because my themes fully support RTL and flip the sidebars.

I'm sorry, I don't think "momentarily stuck" is something we should consider so grave that justify maintaining the wrong concept that comes with Right/Left.
I published my opinion on the other issue but I really don't think that switching labels is the way to go and I do believe a small change (#65) to the patch applied here (in #55) is all we need to do to close both of these issues for good.

subscribing

Correct me if I'm wrong but I believe Drupal 7 is in a code freeze, which means that issues that could be considered "feature request" have to wait till D8. Honestly when I listen to all the debate that has gone on with this and related issues I find it frustrating that people are giving this so much energy when all we are talking about is Garland, which is not a theme that most respectable developers would use as is on a finished site (unless they don't really care how the site looks). I understand it needs to be customized for rtl conventions, but it would be very easy to switch out these text values with a few lines of jquery on the sites in question (just one solution) or you could just edit those two lines on your own site in the .info file. Not worth having a fit over, and certainly not worth drawing the attention of developers who are working on issues that break the actual functionality of a site.

I'm sure that this comment will inspire some flaming, and I'm sure that someone will promptly change the issue back to active, critical and bug report... I only wish that those who would do this would realize that doing so won't make the code get in to D7. Also, those who keep marking the issue as critical are ignoring the accepted meaning of "critical" within the Drupal project. Critical refers to issues which break a site or render it unusable. This issue may be a matter of taste or a minor bug, but it is certainly not a critical issue. You can always switch themes and voila, problem solved. Setting non-critical issues to critical over and over again just annoys the people who you would want to have on your side (the programmers and maintainers). Not a good idea if you ask me.

Besides, Garland may or may not even exist in future versions of Drupal. I for one am surprised that it still ships with core. Garland isn't essential to the functioning of core, and therefore really isn't core at all except in the sense that it ships with core and is the first theme that is enabled on a new site. This is really just a tradition, not a necessity (perhaps even a tradition that should be changed).

In my opinion those who take this issue to heart would be better off putting their energy into a publicly available rtl friendly theme for Drupal that does exactly what they want it to.

This issue is not specific to Garland; the code defining these regions lives in the theme system and is inherited by default by all themes. Plus, it serves as a "best practices" example even for themes that are overriding this list with their own regions. Finally, you do not have to look far around the Internet to see that Garland is a popular, widely-used theme.

I agree there is no way in the world this is critical, though :)

This may not be critical but is very important and must be fixed, the sooner - the better.
Just take a look at any of the important themes - Fusion, Zen, Acquia Marina as well as the core candidates - Bartik and Corolla and many others, non of them use left/right.
Using left/right in core (especially if just for display) is unprofessional and inconsistent and nobody here says otherwise, just that it is too late or that it is not important enough. well, I don't know about too late but I don't see why it should be, as we are still in alpha and we still fix bugs all over the place. about importance - it is important enough, at least for some people, the others are just indifferent.
IMHO this is RTBC, no work needs to be done here, and no attention is to be drawn from developers who are working on issues that break the actual functionality of a site (#78) just need someone to commit it.

Now that Bartik is our new default theme - not accepting #65 is just weird.

Please don't RTBC your own patches. And the patch in #65 doesn't even use the same exact phrasing that Bartik does...

Since Bartik currently does not use "left" and "right" in the user-facing text (but instead uses "first" and "second"), this issue does seem more important, because the terminology isn't even consistent across core. Obviously, another possible solution would be to switch Bartik to use "left" and "right" like the others, and explore the other methods discussed above to have this terminology change appropriately for RTL languages.

I understand the point about not marking as RTBC my own patches but this issue gets so little attention that I don't see who else will do it.
I understand that more that 95% of drupal users and developers couldn't care less about these issues, but these issues are more then critical for (aspecially first-time) RTL users, so we do what we can (marking as critical and rtbc ourselfs) to get some attention in this race of resolving issues and making drupal 7 the best we can.

Regarding your suggestion about making bartik use "right" and "left", sorry, but I honestly hope no-one will take it seriously as this is a major regression. People made a lot of effort to make bartik an example of a well written bi-directional theme, taking it back to the wrong concept of using "right" and "left" in sidebars naming will make many people sad and frustrated.

This patch uses the same conventions bartik is using :

> so we do what we can (marking as critical and rtbc ourselfs)

Hmm, we'll you shouldn't do it.

Anyway, since it's now the same as Bartik, if tests are green then it's RTBC.

I'm not opposed to this change personally, but it seems a little odd to call this RTBC so cavalierly when it goes directly against the decision that was made (and committed) earlier in this issue, for a variety of reasons that are all carefully laid out in the discussion above.

At least it might be useful to hear more from the people who participated in the original discussion.

> At least it might be useful to hear more from the people who participated in the original discussion.

Fair enough.

I think that for RTL people such as tsi, yhager and myself, no matter how we put this -- If it's written Left but on our language it appears on the right then it's a bug.
Since the best way to solve problems is to follow core - and here we have two options to choose from- I think we should follow the correct(er) option.

> I'm not opposed to this change personally

So does each and every commenter on this issue since July 2009. If someone still believes "right" and "left" aren't wrong (and not only for RTL, think about two sidebars on the right for example) then they should say it, otherwise, this issue should be finally fixed.

If it's written Left but on our language it appears on the right then it's a bug.

Agreed. Any thoughts on using t() to address this, as described in #73?

I don't have time to read this whole thread, so my apologies if I misunderstand what's going on. But here's what I think is going on (in the most recent rounds of discussion):

Drupal 7 has now included left-to-right switching to right-to-left internationalization support (full support) directly into core. It's a key goal in the new version.

Bartik has named the two sidebars as follows:
• var: $sidebar_first / label: Sidebar first
• var: $sidebar_second / label: Sidebar second

Core itself is as follows (which means Garland, Stark, and any other site that doesn't define custom regions has):
• var: $sidebar_first / label: Left sidebar
• var: $sidebar_second / label: Right sidebar

But there is nothing in core that makes the labels flop when switching the language direction — $sidebar_first is always marked "Left", whether LTR or RTL. And $sidebar_second is always labeled "right" — whether it's on the right side or on the left side.

Webchick, when she committed the patch to make the change to the variable name, at:http://drupal.org/node/226587#comment-1881580 said:

The part which gives me serious pause of course is:

- 'left' => 'Left sidebar',
- 'right' => 'Right sidebar',
+ 'sidebar_first' => 'Left sidebar',
+ 'sidebar_second' => 'Right sidebar',
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).

I agree with the idea in that quote — if there is a debate being made that "sidebar_first" *should* be "Sidebar first" for code consistency.... that doesn't beat out the need for human-understandable terms. And "Left sidebar" is better for humans to understand. If it were actually on the left all the time.

I think there was a giant oversite when the original patch was committed — and no one realized that in RTL, the labels would be wrong and would make no sense.

IMO, if the words "left" and "right" are going to be used in the labels, then the labels must swap places. But sadly that would likely create a bunch of other problems. In no other case do region labels swap names, so we'd be introducing a potential wtf. Plus, what about themes that have other regions besides the sidebars that flop to the other side in RTL/LTR? Bartik has triptych first, middle and last; and footer column 1st, 2nd, 3rd, and 4th. There are more and more complex region layouts in contrib these days too. Any solution with label swapping must support what they are all doing.

It seems the simplest solution is to change the labels in core to be "Sidebar first" and "Sidebar second". Perhaps something more complex can be done in Drupal 8. This would solve the immediate problem at hand — where the right sidebar is labeled "left" in RTL.

Accordingly, I think the patch in #83 should be committed.

> Agreed. Any thoughts on using t() to address this, as described in #73?

IMO, The translation of a word shouldn't be it's exact opposite. i.e Left shouldn't be translated to right in RTL languages :)

Plus, what about themes that have other regions besides the sidebars that flop to the other side in RTL/LTR? Bartik has triptych first, middle and last; and footer column 1st, 2nd, 3rd, and 4th. There are more and more complex region layouts in contrib these days too. Any solution with label swapping must support what they are all doing.

The triptych and footer don't need label swapping because the regions display all in a row, right next to each other (so "first", "second", "third", etc is definitely a reasonable way to label them). The sidebars are quite different in that respect; they do not display next to each other on the page, so there is a lot more room for confusion.

There may be a consistency argument that says we should use "first", "second", etc for all regions if we are using it for some of them, but it's not a completely obvious one.

IMO, The translation of a word shouldn't be it's exact opposite. i.e Left shouldn't be translated to right in RTL languages :)

As far as I understand, context was introduced to the translation system for exactly this kind of situation - where you want to translate a word one way in a certain situation that is different from the way you would translate it in other situations.

***

In any case, looking through the code, Drupal 7 does not appear to translate these region names AT ALL at the moment, which appears to be a large regression from Drupal 6? Compare:
http://api.drupal.org/api/function/system_region_list/6
http://api.drupal.org/api/function/system_region_list/7

It appears this was introduced (unintentionally, I assume) in #511284: Add html_top and move the admin toolbar into html_top. Am I mistaken?

We don't have to fix that here, but if it isn't fixed somewhere then not only would "left sidebar" be incorrect on a site with a RTL language, but it would also display in English rather than in the correct language. We might be able to knock both of these off at the same time...

Let's get both options under consideration. I've rerolled #83 and attached it, and am also attaching a second patch based on the alternative proposal. This (by its very nature) fixes the translatability issue as well, so if not going with that approach we'll need a separate issue for that.

I don't have a strong opinion between these, but we should make a decision based on usability here (i.e., what is the best overall text to present in the interface on a variety of different kinds of sites, taking into account all the factors discussed above). Adding another usability-related tag for that purpose.

Looks like we are going to live with this inconsistency until Drupal 8.

I moved the translation bug discussed above to its own issue (#1050686: Theme region names are no longer translated), since that fix still needs to go into Drupal 7.

By the way, here are a couple informal usability test results showing user confusion regarding the "Sidebar first" and "Sidebar second" terminology:

http://drupal.org/node/601932#comment-3570926
"... Looking through the regions in the dropdown menu, she asked "Why is there nothing that says 'right'?" (since she knew she wanted to put it on the right side of the page) ..."

http://drupal.org/node/601932#comment-3617446
"... She also couldn't parse the meaning of "Sidebar first" and "Sidebar second", i.e. which one is the left one ..."

Those tests were conducted as part of #601932: Allow dashboard to limit available blocks and were designed to test something else, but confusion over the meaning of these region names was something that came up with both of those two test subjects while the test was being conducted. Food for thought for the issue at hand here.

With the layout initiative, this should even make more sense. The labels should not be the signification, the actual interaction should do that.

Er. Wait. Which patch here is RTBC?

#93: rtl-sidebars-nomenclature-226587-83.patch queued for re-testing.

Retesting against latest HEAD since it has been over a year.

I think the issue summary needs an update.

Re Rolled for a/core/modules/help/help.api.php and b/core/modules/system/system.module.

Regarding the changes in .info file of bartik, In drupal 7 we have options like regions[sidebar_first] = Sidebar first
regions[sidebar_second] = Sidebar second. In drupal 8 we have different coding style to define the regions inside a theme.info.yml file.

Re-roll

This issue really needs a summary update (including discussion of what the sidebar regions are being named and why) before the patch can be effectively reviewed.

#108 still applies. Removing the "Needs reroll" tag in preparation for Drupalcon Los Angeles sprints.

Regions have been renamed to Sidebar first, Sidebar second in Drupal 8 and in default theme ( Bartik ) the sidebar is correctly placed when language changed to Arabic ( RTL).

I do not see any such renaming - the default theme regions are still "Left sidebar", "Right sidebar", etc. (To see that, go to admin/structure/block/list/classy on a fresh installation of Drupal 8.)

I also think the version of the patch here that adds the "theme region label" translation context could probably be backported to Drupal 7 (since these are admin-facing strings and this issue fixes a usability bug), so adding the tag for that. The last couple rerolls of that patch look like they may be incomplete, so setting this back to "Needs work".

ThemeHandler.php lines 260 /261 needs updated to correct issue in Classy where regions are still incorrectly named - will provide a patch tomorrow if no one else provides one first.

That wouldn't just affect Classy though; it would affect the default regions for all themes that don't define their own. So it would be an updated version of the second patch in #93.

Per #95 I think the usability of this solution would be bad - we should be getting rid of names like "Sidebar first" and "Sidebar second" that have proved to be confusing, rather than expanding their use.

Sorry for the confusion - i was under the impression that the naming of sidebars left / right was a useability issue and that was why sidebar first / second was adopted.
I just think that whatever decision is made of the correct naming of sidebars, it is made consistent across core.

Let's see if I understand this correctly...

I arrived here after noticing, to my surprise, that in the Classy theme the sidebar_first region is labeled "First sidebar". At first this inconsistency seems unneeded, confusing, and easy to fix.

Of course, things turned out to be more complicated: while the usability aspect (#95) asks for region labels that refer to a position on the page ("left" and "right"), RTL languages require us to mirror the page layout, making it impossible to use hard-coded "left" and "right" names.

It has also been pointed out that a theme can always choose to place regions where ever it pleases. While this is true, we have no choice but to start with a basic set of assumptions. Otherwise we might as well give regions a uuid and be done with it.

While discussing this with David_Rothstein in IRC, I realized that I have always interpreted "first sidebar" and "second sidebar" as describing the order in the HTML source code, which is not necessarily the order on the page in the reading direction. David suggested in #73 that we can use translations to "convert" region labels from left to right and vice versa. If we can agree on that approach, the current situation is not really broken, but we only need correct translations. From our IRC conversation:

(22:07:43) marcvangend: David_Rothstein: So, summarizing: You prefer to leave the current situation as it is, where 1) the machine names of the regions relate to their position in the HTML, 2) the human readable labels relate to the position on the page (assuming you have a large enough screen), 3) it's the translator's responsibility to translate "Left sidebar" with "Right sidebar" if it's a RTL language, and 4) it's the themer's responsibility to position the sidebar_first region on the right side of the layout, depending on the direction of the language.

(22:10:42) David_Rothstein: marcvangend: Well, mostly - it would be best if the machine names match the human readable names but it's probably too late to change the machine names in either D7 or D8 (and I think you have a good argument for making the machine names correspond to the position in HTML - I hadn't thought about that myself). Also, I seem to remember saying we should give the translators some context (using the 'context' para

The most difficult part here may well be the translation context. There should be no doubt for the translator of an RTL language what he/she should do, yet a translation context is not meant for long instructions. Also, when I look at the current code in \Drupal\Core\Extension\ThemeHandler::rebuildThemeData(), I don't see how we should add a translation context specifically to sidebar regions, because the region labels are translated elsewhere.

TL;DR:
As long as we have no proper way to swap regions or region labels based on the language direction (that is what #506776: Switch labels for some theme regions when language is RTL is about), the best way to solve the confusion is to make it the translator's responsibility to translate "left" with "right" and vice versa when translation region labels in an RTL language. This approach assumes that the themers make sure that the positions of sidebars are swapped in an RTL context (they often do). Adding a translation context is needed to help translators do this correctly.

I propose that we close this issue as "works as designed" and start a follow-up issue to add the translation context to sidebar regions.

@marcvangend We can go further: naming these regions to "sidebar" are valid only when we thinking of a desktop layout and we have an assumption about the layout what is defined in CSS. And on a narrow ("mobile") screen it's not likely to have more things side by side...

@marcvangend We can go further: naming these regions to "sidebar" are valid only when we thinking of a desktop layout and we have an assumption about the layout what is defined in CSS. And on a narrow ("mobile") screen it's not likely to have more things side by side...

Agreed with @marcvangend. We've actually done many round trips to establish these labels, I don't think we can now also start taking into account HTML hierarchy as ordering :) not very 2015 anyway!