Closed Bug 437891 Opened 16 years ago Closed 13 years ago

[tracker] RTL support for SUMO

Categories

(support.mozilla.org :: Localization, task, P4)

Product:
support.mozilla.org
Component:
Localization
Type:
task

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
2011-10-11

People

(Reporter: tomer, Assigned: rrosario)

References

(Depends on 1 open bug,
URL
)

Details

(Keywords: l12y, rtl, Whiteboard: start at comment 35) 

Currently, every page on sumo displays from left-to-right, even for rtl languages such as Arabic and Hebrew. We should get it fixed as soon as possible, as the Help files are hardly readable in the current state.
Brian, how does the redesigned website handle RTL languages? This should be handled the same way as mozilla.com handles it (if it does handle it at all?)
Depends on: 435555
What about the {r2l} tag?
(In reply to comment #1)
> Brian, how does the redesigned website handle RTL languages? This should be
> handled the same way as mozilla.com handles it (if it does handle it at all?)

David: Let's make a note to discuss it tomorrow, I imagine it can be done but know too little about it to give a definitive response.
Let's target this to 0.7 but I propose we give this a high priority to get this out in a downtime window within the next couple of weeks, if possible.

Tomer, could you assist in what needs to be done and what the best way would be to handle this?
Target Milestone: --- → 0.7
(In reply to comment #4)
> Tomer, could you assist in what needs to be done and what the best way would be
> to handle this?
I'm not sure if I understand your request. Basically we need the whole page to get direction:rtl CSS rule, and everything to sit correctly. Most of the time we expect to see the whole page 'mirrored' on RTL layouts, so the navigation bar should also be moved to the other side (In case of float layouts, where it might require some more tweaks than just changing the page direction. 
That's the kind of advice I meant. :) Things like:

* Should we just right-alight the paragraphs or actually mirror the artwork (I assume the latter based on your last comment)
(In reply to comment #6)
> * Should we just right-alight the paragraphs or actually mirror the artwork (I
> assume the latter based on your last comment)
Artwork should not be mirrored, but only where it is needed, such as background pictures. 

For example, the current moco page for Firefox has that issue, and the backgrounds has to be mirrored. http://he.www.mozilla.com/he/firefox/

Looking deeper into this, this looks significantly more complicated than I first thought.  It seems like the easiest thing to do is to modify the handling of the {r2l} tag so that it sets a class, and then use CSS to right-align that text.  This, however, would only add rtl support for the page content.  Reversing the entire layout is a significant task.

It seems like the primary concern is that the text is in the wrong direction, making it difficult to read.  Use of the {r2l} tag will fix this.  Would this be a satisfactory solution?
Priority: -- → P2
Mass moving P2 bugs to 0.6.2 milestone.
Priority: P2 → --
Target Milestone: 0.7 → 0.6.2
Assignee: nobody → bkrausz
Are things like the modules on the side localizable/going to be localized?
I thought I already filed a bug for that long ago. I guess not. :-(
I just filed bug 444439.
So it seems that the only things that can be localized are the page content, top nav, header, and footer.  The problem comes when only half of these are localized.  If I rtl everything, the site becomes just as unreadable.  We need some way to only rtl what is translated, which we don't have.  The only other option is to do something like this for each translation:

<span class="rtl">TRANSLATION</span>.

I can define .rtl to text-align right and reverse direction.  That way as things get translated they will be in the correct direction.  This seems like the best compromise, especially considering how little of the site's static content is currently localized.

Another option is to translate is, and then have me push out the hard-coded rtl after the fact, that way it will only look bad for at most a week after being translated, instead of however long it takes to actually get the translation.
Tomer, can you provide advice here?
(In reply to comment #12)
> So it seems that the only things that can be localized are the page content,
> top nav, header, and footer.  The problem comes when only half of these are
> localized.  If I rtl everything, the site becomes just as unreadable.  We need
> some way to only rtl what is translated, which we don't have.  The only other
> option is to do something like this for each translation:
When we are trying to access an article that is missing for the requested language, there is fallback to English, right? Can't we use that fallback and put LTR depend on the displayed language? 
I'm referring to page elements such as the modules, which obviously shouldn't be rtl if they're English.  We can't fallback for specific parts of the page (at least not in a clean way that I can think of).
IMHO, that parts should be translated. The main article can be kept in LTR in case it is required.
Hey Nelson,

Is there a way to tell:
1) That we are on a locale that needs rtl
2) That the page is translated into that lang (i.e. we're not showing english)

If not we need to add or hack out this functionality.  Please advise.

Thanks :)
Assignee: bkrausz → nelson
1) In TikiWiki, the standard way to tell the system that a lang is rtl is to amend setup/language.php -- at the end of it, there is something that sets $prefs['feature_bidi']. This is used throughout TikiWiki to trigger rtl behavior and use of the styles/BiDi/BiDi.css style sheet.

Change the language to Arabic or Hebrew and you will see what I mean.

2) There are a few language global prefs that might be useful: $prefs['language'] is the user's language, which could have been detected from the browser. $prefs['site_language'] is the site default language so is distinct from the other pref. As for the page content itself, on tiki-index.php, $pageLang is assigned to Smarty. So if you look for that in Smarty, you will get the page language, or if you do a $smarty->get_smarty_vars('pageLang'); in php you should get the same thing...
Target Milestone: 0.6.2 → 0.6.3
Target Milestone: 0.6.3 → 0.6.4
unassigning myself and moving to 0.7 in view of other higher priority bugs - someone else might be able to pick this up though.
Assignee: nelson → nobody
Target Milestone: 0.6.4 → 0.7
Target Milestone: 0.7 → 0.8
Target Milestone: 0.8 → 0.9
Target Milestone: 0.9 → 1.0
Any chance to get it fixed? SUMO is currently broken for RTL users, and this may be one of the reasons users will abandon Firefox.
This bug is scheduled for SUMO 1.0, which will focus on l10n. The tentative date for 1.0 is late March <https://wiki.mozilla.org/Support/SUMOdev_Meeting_Notepad>.
Just hold on a bit longer! :-)
In all fairness though, we're stuck on the details of what needs to be fixed here. bkrausz and I chatted about this back in July 16th and comment 17 is the result of that. We need:

* Templates that are RTL
* The ability to display the actual article in RTL if it's actually translated (i.e. the fallback to English needs to remain LTR).

Also, someone needs to be assigned to fix this as bkrausz isn't available.
(In reply to comment #22)
> * The ability to display the actual article in RTL if it's actually translated
> (i.e. the fallback to English needs to remain LTR).

Well, this might be easy. See this pseudo code - 

if (document language == {'ar', 'fa', 'he'}) 
  document.direction = 'rtl';
else
  document.direction = 'ltr';
Based on comment 22 and 17, I think we need the following here:

1. RTL support in the theme.  This may be the biggest work here.
2. Make sure that our RTL locales are correctly marked as such in tiki-wiki.  The RTL locales currently are ar, fa and he.
3. Set the default direction of the article text to LTR, and only set it to RTL when the author explicitly wants that (for example, by using {r2l}).  This is simple, and can be done using a few CSS rules, I guess.  This means that translators for RTL locales have to use {r2l} in every page, but I think it's a fairly small cost to get the benefit of correct direction for both translated text and English fallbacks.

And I *think* that point 2 in comment 18 nullifies my third item here, but I'm not sure.
Comment 24 wraps up nicely what needs to be done here. We should aim to have this fixed in SUMO 1.2, which means Q2 2009. Both 1.0 and 1.1 are Q1 goals and unfortunately we don't have the cycles to get this fixed and tested within that timeframe.

Looking at the status of the three affected locales, it seems that none of them actually has any support articles translated except Hebrew, which only includes the script imported Firefox 2 product help and original file names as article titles (e.g. mouse_shortcuts-he rather than "Mouse Shortcuts" in Hebrew). So, while Tomer is right in comment 0 that the documentation is hardly readable today, the truth is we hardly have any documentation to begin with.

-> Future, until we get new milestones setup for the support.mozilla.com Bugzilla product.
Component: General → Localization
QA Contact: general → localization
Target Milestone: 1.0 → Future
The Hebrew translation of the Options window article is the only left to be purged, and I'm have a heck of a time trying to edit it. Tomer, is this bug a blocker for the Hebrew locale on SUMO? Should we disable it, until this get's fixed?
Target Milestone: Future → 1.2
I don't think the Hebrew version of SUMO should be disabled, as Google is indexing the pages and I see people linking to the articles there. 

As for the options article, I'll work on it at the moment I'll have some free time.
Assignee: nobody → smirkingsisyphus
Target Milestone: 1.2 → Future
Any progress here?  I also filed bug 504056 about adding a few useful editor toolbars for RTL locales.
Assignee: smirkingsisyphus → jsocol
adding to 1.4.1 triage
Target Milestone: Future → 1.4.1
Moving to 1.6 -- this is a major project and needs a milestone all to itself.
Target Milestone: 1.4.1 → 1.6
Blocks: 531939
1.6 has become a general l10n milestone, and I fear that this may get deferred again, because the hours required.

Is it possible to break this down into smaller tasks, that can be spread out of a series of SUMO releases?
Chris, I haven't had a chance to look into this yet, but if 1.6 remains an L10n milestone, this should stay. Reading through the comments, it seems--though I don't know--that partially completing this could make some parts of the site unreadable. I think this is 1/3rd of the next l10n milestone, along with moving to gettext and the content l10n workflow.
As we work on Kitsune themes, let's get this right from the beginning. This is on everyone, so unassigning from just me.
Assignee: james → nobody
Target Milestone: 1.6 → 2.0
Priority: -- → P4
Pushing out low-priority bugs.
Target Milestone: 2.0 → 2.1
Target Milestone: 2.1 → 2.2
Target Milestone: 2.2 → ---
OK, let's start this over. Almost none of the code that existed the last time this was touched still exists. Making this into an RTL support tracker.

One quick thing to start may be the CSS from bug 676262 comment 0, but there's obviously a lot more to do to do this right. Let's see if we can figure out where we want to go then try to break it up into a number of atomic steps.

So, my assumption, based on mozilla.org, and please correct anything wrong here, is that we want:

* Text-direction set correctly in RTL languages.
* Flip arrows and other graphic, directional assets.
* Flip form controls when they run LTR.
* Flip page layout (e.g. gutters, CTAs, etc).
* Flip content layout (e.g. floated boxes, images, etc., within KB content).

I'm sure I left things off or gotten them wrong, so please add/remove from that list.

Once we nail down at least a partial list we'll try to see what's low-hanging (i.e. easy to do and isn't blocked by the ongoing UX work) and figure out where we can work that in to our schedule coming up.
No longer blocks: fx3-l10n-he, 531939
Summary: SUMO theme lack of RTL support → [tracker] RTL support
Whiteboard: start at comment 35
Re. comment #36

Hi James,

Thanks,

Generally sounds good (I don't know what are gutters and CTAs though :)). I assume it was implied, but if not, I'll mention it too - basically all the margins/paddings/borders you might have the relate to right/left should be flipped as well.

Also note that merely setting direction: rtl and text-align: right will by itself change the flow of div's in the text and could do it 'right' to begin with. 

It would be the easiest to start with just setting direction: rtl on the html {} css block - and simply see what breaks, then fix it. sometimes you would NOT flip something, due to the fact that it does need to look the same in any language... 

We can do these changes live on the chat or something, and I can comment, though for most part, you would see yourself what is wrong after you've switched the directionality. We the Hebrew people could alert on bad text flow :)
Changing demonstration page with more relevant link. 

(Kadir, previous link is pointing to 404 page which probably got lost during one of the recent SUMO upgrades. You might want to set some redirectors to make sure users won't face dead links)
URL: http://support.mozilla.com/he/kb/usin... → https://support.mozilla.com/he/kb/ask
Depends on: webrtl
(In reply to James Socol [:jsocol, :james] from comment #36)
> * Text-direction set correctly in RTL languages.
> * Flip arrows and other graphic, directional assets.
> * Flip form controls when they run LTR.
> * Flip page layout (e.g. gutters, CTAs, etc).
> * Flip content layout (e.g. floated boxes, images, etc., within KB content).

I think this is a good list to start with.  Depending on how much bidirectional content we're going to have on SUMO, we might also need to do something about that as well.
Summary: [tracker] RTL support → [tracker] RTL support for SUMO
Is it possible to customize the stylesheet for specific languages? We wish to change the fonts for Hebrew to sans-serif, and get rid of that italic fonts as there is no good italic fonts for Hebrew.
(In reply to Tomer Cohen :tomer from comment #40)
> Is it possible to customize the stylesheet for specific languages? We wish
> to change the fonts for Hebrew to sans-serif, and get rid of that italic
> fonts as there is no good italic fonts for Hebrew.

You should file a new bug and have it depend on this one. We're planning to land the RTL patch we have, because it's already a big improvement, and then iterate on that.
Assignee: nobody → rrosario
Target Milestone: --- → 2011-10-11
Initial RTL support landed:
https://github.com/jsocol/kitsune/commit/6e580229b77316d80f817d541216fb1068d910d8

I hope it is a usable starting point. Please file new bugs for issues.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
(In reply to James Socol [:jsocol, :james] from comment #41)
> (In reply to Tomer Cohen :tomer from comment #40)
> > Is it possible to customize the stylesheet for specific languages? We wish
> > to change the fonts for Hebrew to sans-serif, and get rid of that italic
> > fonts as there is no good italic fonts for Hebrew.
> 
> You should file a new bug and have it depend on this one. We're planning to
> land the RTL patch we have, because it's already a big improvement, and then
> iterate on that.

\o/ It's already sans-serif here:

https://support.allizom.org/he/home
https://support.allizom.org/he/kb/tabbed_browsing-he

But like Ricky said, let's do new bugs for follow-up issues like removing italics.
Target Milestone: 2011-10-11 → ---
Target Milestone: --- → 2011-10-11
https://support.allizom.org/he/kb/tabbed_browsing-he

* Why is the search field has some padding? Is it expected?
* The version/OS chooser at the sidebar as two cross signs, that I think should start ar the same position. Also, for some strange reasons when you click on it you see the keyboard caret (this might be a browser bug).
Verified basic implementation of the RTL text, and sidebars/logos have been moved.  All other issues should be filed separately.
Status: RESOLVED → VERIFIED
I am unable to see any difference on support.mozilla.com. When it is expected to appear on the public site?
Filed bug 693471 regarding the extra padding in the search field.
The release is scheduled for tomorrow 10/11, 3pm West Coast time.
Depends on: 705063
You need to log in before you can comment on or make changes to this bug.