Last modified: 2012-04-19 21:10:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 6100 - Allow different directionality (rtl/ltr) for user interface and wiki content
Allow different directionality (rtl/ltr) for user interface and wiki content
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
1.7.x
All All
: Highest enhancement with 15 votes (vote)
: 1.19.0 release
Assigned To: Robin Pepermans (SPQRobin)
: i18n, patch, patch-need-review
: 4066 4102 4124 4953 6756 9137 19228 28228 (view as bug list)
Depends on:
Blocks: rtl 29218 12151 12415 13447 24692 28902
  Show dependency treegraph
 
Reported: 2006-05-26 19:56 UTC by Pablo Saratxaga
Modified: 2012-04-19 21:10 UTC (History)
18 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
patch for Bidi separation between layout and content (13.10 KB, patch)
2006-05-26 19:57 UTC, Pablo Saratxaga
Details
updated version of the patch (14.68 KB, patch)
2006-05-26 22:03 UTC, Pablo Saratxaga
Details
updated patch (21.46 KB, patch)
2006-05-27 13:46 UTC, Pablo Saratxaga
Details
final patch (52.60 KB, patch)
2006-05-28 20:12 UTC, Pablo Saratxaga
Details
final patch (54.29 KB, patch)
2006-05-28 21:23 UTC, Pablo Saratxaga
Details
Problem Screenshot (28.40 KB, image/png)
2006-05-31 15:34 UTC, Rotem Liss
Details
Patch to fix the problem (386 bytes, patch)
2006-05-31 15:52 UTC, Rotem Liss
Details
Patch to fix some lists (1.10 KB, patch)
2006-05-31 16:42 UTC, Rotem Liss
Details
fixes tables of forms in RTL mode (left/right values) (18.08 KB, patch)
2006-05-31 20:33 UTC, Pablo Saratxaga
Details
File indicating major screwup in browser handling of directionality (633 bytes, text/html)
2007-12-17 20:57 UTC, Aryeh Gregor (not reading bugmail, please e-mail directly)
Details
Very incomplete patch, taking a somewhat different approach to the above patches (21.97 KB, patch)
2007-12-18 03:28 UTC, Aryeh Gregor (not reading bugmail, please e-mail directly)
Details
deonstration of LTR preferences on RTL wiki (30.18 KB, image/png)
2011-06-29 19:15 UTC, Mark A. Hershberger
Details

Description Pablo Saratxaga 2006-05-26 19:56:57 UTC
Now that it is possible, trough preferences or uselang=, to given a language for
the interface that it is different of the local wiki language; it is needed to
better separate and handle what is interface layout, and what is local wiki data
content.

This patch does just that.

What it does:
* adds a <div id="realContent"> </div> around the real wiki content
* if user language is the same as the local wiki language, it doesn't do
anything else (current behaviour)
* if user language is different than local wiki language, then:
** the main language and directionality for the pages are set according to user
language, not wiki language
** id="realContent" is set to language and directionality of the local wiki
** the "firstHeading" is set to language and directionality of the local wiki
(only for pages not in Special:, and for actions 'view' and 'history')
** toctitle (but not the toc itself) and editsection are set to user language
and directionality

* two global functions are added, layoutdir() and contentdir() that return
either empty strings or things like " lang='ar' dir='rtl'" as needed
respectively for the user language and the local wiki language
* rtl CSS files are split in two, one used when user language is rtl, one used
when wiki content is rtl
Comment 1 Pablo Saratxaga 2006-05-26 19:57:47 UTC
Created attachment 1835 [details]
patch for Bidi separation between layout and content
Comment 2 Pablo Saratxaga 2006-05-26 22:03:51 UTC
Created attachment 1839 [details]
updated version of the patch

I removed the changes to toc and editsection (it is problematic due to caching)


Fixed problems in old skins too
Comment 3 Pablo Saratxaga 2006-05-26 23:53:31 UTC
*** Bug 4124 has been marked as a duplicate of this bug. ***
Comment 4 Pablo Saratxaga 2006-05-27 00:02:00 UTC
*** Bug 4102 has been marked as a duplicate of this bug. ***
Comment 5 Pablo Saratxaga 2006-05-27 00:03:40 UTC
*** Bug 4066 has been marked as a duplicate of this bug. ***
Comment 6 Pablo Saratxaga 2006-05-27 13:46:58 UTC
Created attachment 1843 [details]
updated patch

this updated version of the patch also uses user language for several Special
pages, redirects (the small redirect icon), etc. and put the upper list of
links (usrpage, preferences, my follow,..., log out) in reversed order in RTL
display
Comment 7 Pablo Saratxaga 2006-05-27 13:51:33 UTC
*** Bug 4236 has been marked as a duplicate of this bug. ***
Comment 8 Pablo Saratxaga 2006-05-27 13:53:50 UTC
*** Bug 4953 has been marked as a duplicate of this bug. ***
Comment 9 Pablo Saratxaga 2006-05-28 20:12:01 UTC
Created attachment 1851 [details]
final patch

final version of the patch;
if fixes more RTL and Bidi issues
in various Special: pages

only remaining problems are from lists made from QueryPage.php (the link to
articles should be enclosed in a span dir=rtl|ltr if user directionality is
different than wiki disrectionality)

and also issues related to browser rendering in RTL mode (in firefox
bullets/numbers of lists are at a negative offset; nested fieldset are left
aligned (they should be right aligned in RTL)

and also, maybe renaming contentdir() and layoutdir() functions to match better
the coding style.
Comment 10 Pablo Saratxaga 2006-05-28 21:23:44 UTC
Created attachment 1852 [details]
final patch

ok, a last one :-)

This one has improvements on recentchanges (and other using ChangesList.php);
more direction marks (lrm or rlm, depending on user language) are inserted,
making lines more robust; also, U+202C (pop direction formatting) is inserted
after article title and user name fields; so if either article or user name has
special control formating characters, that won't distroy the recentchanges, nor
even the change line.
That solves vandalization attemps as in bug #3696
Comment 11 Rotem Liss 2006-05-31 15:32:35 UTC
Applied to r14495 by nikerabbit, however the patch is not perfect, and causes
some problems. A screenshot is coming soon. I'm sure fixing the problems will be
very easy, so I'm starting debugging the problem.
Comment 12 Rotem Liss 2006-05-31 15:34:53 UTC
Created attachment 1863 [details]
Problem Screenshot

The bullets are improperly aligned, and the personal bar (above, the user name,
talk page, etc.) is reversed.
Comment 13 Rotem Liss 2006-05-31 15:36:51 UTC
(In reply to comment #12)
> and the personal bar (above, the user name, talk page, etc.) is reversed.

However, this may be the right behavior. By the way, the problems are also shown
in the normal view, and they exist only in RTL view.
Comment 14 Rotem Liss 2006-05-31 15:52:50 UTC
Created attachment 1864 [details]
Patch to fix the problem

I think this patch will fix the problem.
Comment 15 Rotem Liss 2006-05-31 15:55:15 UTC
By the way, the patch must be commited today, else all the RTL wikis will be broken.
Comment 16 Rotem Liss 2006-05-31 16:01:39 UTC
Applied to r14496 by nikerabbit. Thanks.
Comment 17 Rotem Liss 2006-05-31 16:42:28 UTC
Created attachment 1865 [details]
Patch to fix some lists

When replacing the direction, the lists outside the content should be fixed,
but they are not – the lists fix is defined in "content_rtl.css", which is
not changed. This patch fixes this minor problem.
Comment 18 Pablo Saratxaga 2006-05-31 17:21:22 UTC
Yes, as said above, the remaining problems are CSS ones; I'm not very good at CSS.

(BTW, isn't in CSS a way to define things depending on directionality? then a
single CSS file will be enough)

The reversing of the userbar is indeed on purpose, see bug #4236 asking for that.

As for the remaining RTL rendering bugs, those are also present on current
version, not created by the patch, but not solved either.

The patch just sets directionality according to user interface language (instead
of wiki language); and solve various bidi/rtl problems (but not all)
Comment 19 Pablo Saratxaga 2006-05-31 20:33:16 UTC
Created attachment 1867 [details]
fixes tables of forms in RTL mode (left/right values)

This is an easy and safe patch that fixes some reamining problems in various of
the tables in Special pages with forms.

It changes hardcoded "left" and "right" depending on the directionality; eg:

 $left = ($wgLang->isRTL()) ? "right" : "left";
 $right = ($wgLang->isRTL()) ? "left" : "right";

SpecialUserlogin.php has:

 $template->set( 'rtl', $wgLang->isRTL() );

so directionality can be requested from the template templates/Userlogin.php
Comment 20 Rotem Liss 2006-11-06 18:02:06 UTC
*** Bug 6756 has been marked as a duplicate of this bug. ***
Comment 21 Rotem Liss 2006-11-08 13:29:32 UTC
*** Bug 6756 has been marked as a duplicate of this bug. ***
Comment 22 Rotem Liss 2007-03-02 14:38:09 UTC
*** Bug 9137 has been marked as a duplicate of this bug. ***
Comment 23 Pablo Saratxaga 2007-03-07 16:56:59 UTC
It seems the patch hasn't been applied?
What was the problem? it worked very nicely.
Comment 24 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-03-07 17:02:31 UTC
We have limited developers, each of whom has limited time.  Furthermore, it's unlikely that 
patches from 10 months ago will apply cleanly.

I'm putting this on my to-do list, but I can't promise I'll get around to it anytime in the near 
future.
Comment 25 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-09-09 23:59:23 UTC
Committed the user login template changes in improved form, r25705.  I plan to look at the broader issue later.
Comment 26 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-17 20:57:52 UTC
Created attachment 4445 [details]
File indicating major screwup in browser handling of directionality

I was working on this but ran into a bizarre difficulty.  Attached minimal HTML testcase shows that browsers seem to, under some conditions, perform basic CSS1 layout totally wrong for RTL.  The inline RTL boxes' horizontal padding is simply eaten.  Can anyone explain this?  I'm trying to prepare a patch, but this is making p-cactions display impossible.

Setting document directionality to rtl appears to change nothing.  Basic rendering problems (of different sorts) occur for me in Firefox 2.0.0.11, Opera 9.5 alpha, IE6, all on Gutsy Gibbon (IE6 courtesy of Wine).

Have to go now, I have a final to study for, but if anyone could figure this out it would be great.  I plan to compare to hewiki to see why that works correctly, when I have time.
Comment 27 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-18 03:28:50 UTC
Created attachment 4447 [details]
Very incomplete patch, taking a somewhat different approach to the above patches

Note, Firefox 3.0 appears to display the previous attachment correctly.  I still need to figure out exactly what triggers the issue in other browsers and how to work around it.  I'll install all the old browsers I can find to make sure this really works before committing anything.

My (very provisional) work so far is attached.  I'm taking a somewhat different approach than the patches here as far as the CSS changes go: I'm just adding them all to main.css with extra body classes for interface language, instead of adding extra CSS files for RTL.  See bug 9868.  (The class names are somewhat clunky, they're provisional.)  If you try viewing an LTR wiki with this patch applied in an RTL interface language, you'll see the problem illustrated in the last attachment pretty dramatically.

I'll incorporate the work from the other attached patches later, right now I'm trying to get basic page views to work right.  I still need to adjust the stuff from the bottom of main.css, and make sure I've gotten all of rtl.css incorporated.  Comments appreciated.
Comment 28 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-24 03:19:13 UTC
Hmm . . . I think a much simpler tactic would be to just change the meaning of body.rtl to mean "RTL interface" instead of "RTL content".  That's more or less what it means now.  That seems much less prone to break.  Then I just have to adjust directionality and tack on some language/dir attributes to things like #bodyContent and .editsection.
Comment 29 Siebrand Mazeland 2008-09-21 23:19:16 UTC
Rotem, Niklas, Aryeh: how about solving this once and for all? You're great minds - at least when combined :P - and this is something worth solving.
Comment 30 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-09-21 23:42:29 UTC
I can't do much given that I'm not competent enough in any RTL language to actually use an RTL wiki much.  This needs to be done by someone who actually uses RTL wikis so they can spot breakage.
Comment 31 Chad H. 2009-06-16 13:08:42 UTC
*** Bug 19228 has been marked as a duplicate of this bug. ***
Comment 32 Niklas Laxström 2009-06-19 13:00:21 UTC
This bug is clearly too big for one person. It would be nice if we got few persons involved active working on this by fixing one piece at a time in the svn and not have too big patches laying around that are not perfect or reviewed.
Comment 33 Chad H. 2009-10-30 23:40:46 UTC
*** Bug 4067 has been marked as a duplicate of this bug. ***
Comment 34 Mark A. Hershberger 2010-01-08 09:52:17 UTC
See r60786 and follow ups that integrate the previous patches (many already applied) and puts lang and dir attributes on interface elements that should be in the user's language.
Comment 35 Mark A. Hershberger 2011-04-05 01:23:57 UTC
This was solved in ResourceLoader, but that had to be backed out.  We plan to find a solution for that and get out a fix by 1.18.
Comment 36 Mark A. Hershberger 2011-05-14 13:01:12 UTC
Trevor, talk Amir about how this is needed for Commons.
Comment 37 Amir E. Aharoni 2011-05-15 05:56:21 UTC
*** Bug 13447 has been marked as a duplicate of this bug. ***
Comment 38 Rob Lanphier 2011-05-23 23:29:12 UTC
IIRC, this functionality was attempted in 1.17, but it was reverted in r81622 because it introduced content problems.  Any future attempts would need to fix the problems found last time around.
Comment 39 Hydriz Scholz 2011-06-02 04:27:18 UTC
Wikimedia Incubator needs this functionality too. Its a multilingual wiki.
Comment 40 Krinkle 2011-06-13 19:24:49 UTC
From BugTriage two weeks ago:
> Possible revert r81622, what do we need to do to bring it back?
> This is a big feature, not just a bug.  
> confirm how things behave in various browsers, see how various parts of the UI behave in different modes, different mixes of LTR and RTL text
> This is probably a prerequisite for allowing different pages to have different content languages set (better support for mixed-language sites like Meta and Commons), but doesn't directly touch it.
> Was originally a trivial change ("one line"), but it broke the actual wiki content (ie. made Arab wiki content left-to-right for English cross-wiki vandalfighters). So it needs to maintain content language directionality for the bodyContent, but allow the skin/layout to adapt to user language. Aside form the ltr on rtl wiki and vice versa, another big (perhaps even bigger) usecase is multi-lingual wikis such as Meta-Wiki and Commons that are currently akward for RTL-users.
> Take to the hackathon in Haifa?  Spec it out there, maybe
Comment 41 Robin Pepermans (SPQRobin) 2011-06-15 17:09:48 UTC
Nikerabbit introduced $wgBetterDirectionality in r69185 (this was not yet mentioned here but is in fact very useful for working to resolve this bug).
When that variable is set to true, the bodyContent contains a div with a lang and dir attribute depending on the site content language.

When r81622 is combined with the changes made under $wgBetterDirectionality (see following code), the main issue mentioned in comment 40 is resolved.

In ResourceLoaderContext.php:
if( $wgBetterDirectionality ) {
	$this->direction = Language::factory( $this->language )->getDir();
} else {
	$this->direction = $wgContLang->getDir();
}

I would commit it, but I thought I'd first post it here.

If this is done, there are only some relatively smaller bugs left (as far as I can see) that can be fixed under $wgBetterDirectionality. When most bugs are fixed, it can eventually be set to true by default.
Comment 42 Niklas Laxström 2011-06-15 17:14:14 UTC
Yes that was the idea with $wgBetterDirectionality but I didn't have time to pursue it further back then.
Comment 43 Mark A. Hershberger 2011-06-15 19:34:53 UTC
Marking as enhancement since this is really a new feature.
Comment 44 Robin Pepermans (SPQRobin) 2011-06-17 11:56:07 UTC
Applied in r90264, and in r90265 I improved the lang and dir of the content div (also when $wgBetterDirectionality is enabled): do not set it for special pages (those are in the user language), and set lang and dir of content of pages in MediaWiki namespace based on the current page instead of site language, e.g. MediaWiki:Message/ar is lang="ar" and dir="rtl"
Comment 45 Robin Pepermans (SPQRobin) 2011-06-17 21:53:19 UTC
Did some further improvements in r90320. If you want to test it, I enabled $wgBetterDirectionality on http://robinpepermans.be/mw-dev/

There are some small bugs left, a list is on http://robinpepermans.be/mw-dev/index.php?title=Project:RTL
Comment 46 Robin Pepermans (SPQRobin) 2011-06-23 21:20:36 UTC
I am working on this, and I think this bug can soon be marked as fixed. :-)

I do have some questions about the exact implementation: please see the "issues" at http://robinpepermans.be/mw-dev/index.php?title=Project:RTL
For example whether the page title should follow the page content language or the user language.

It would also be good if people who know RTL languages can test as much as possible (on my test wiki or you can enable $wgBetterDirectionality on your own wiki).
Comment 47 Niklas Laxström 2011-06-24 08:13:38 UTC
Awesome. Have you checked how far we are from having non-standard page directions in a wiki? I assume there will be some issues with the way ResourceLoader delivers CSS (we would need to split content/ui css or double direction specific rules).
Comment 48 Robin Pepermans (SPQRobin) 2011-06-24 13:34:54 UTC
Yeah, I added css for directions different from the page direction (like [dir="ltr"] [dir="rtl"] and [dir="rtl"] [dir="ltr"]) for editsection class, toc class/id, and ul/ol elements.  I didn't commit that yet because I was not sure that's the best way and it didn't yet work completely for TOC.
I didn't find other stuff that needs to follow page content direction, but it's likely that there's more.

However, I will probably add a hook to the getPageLanguage function so extensions can override the page content language, which would be very useful for multilingual wikis and I want to do this in the WikimediaIncubator extension :-).
Comment 49 Niklas Laxström 2011-06-24 14:25:47 UTC
Now the page related language things are split into two places:
* Direction in Title
* Language in the ParserOptions

Imho both should go through the parser and OutputPage should have methods to specify params for the content area, whether wiki page or special page.

In other words we should pass data, not embed the logic in Skin/OutputPage or make them call other blocks of code.
Comment 50 Robin Pepermans (SPQRobin) 2011-06-24 15:42:19 UTC
I know.. it's split in 2 places now, but I didn't know what the best way was to merge those.

Or should we just move code from title->getPageLanguage() to parser->getFunctionLang() and then let SkinTemplate etc call that?

What would you change in SkinTemplate, because I think it's good as it is now (it adds only a div when viewing a page and not for special pages etc.).
Comment 51 Robin Pepermans (SPQRobin) 2011-06-24 21:33:48 UTC
*** Bug 28228 has been marked as a duplicate of this bug. ***
Comment 52 Derk-Jan Hartman 2011-06-28 11:47:07 UTC
FYI, rtl and ltr are fun, but are we also at least design wise preparing a bit for the next storm, which would be writing-mode ?

http://dev.w3.org/csswg/css3-writing-modes/

Needed for traditional Mongolian for instance which uses: top to bottom , left to right.
Comment 53 Siebrand Mazeland 2011-06-28 12:39:34 UTC
(writing on mobile, haven't searched)

Reply to comment 52: iirc there is an issue closed later because last time I looked up support for vertical text, only one major browser (IE) had some kind of support for it. In any case, let's please continue discussing this on the other bug I'd needed.
Comment 54 Derk-Jan Hartman 2011-06-29 07:23:37 UTC
@Siebrand, new version of the spec was published 2 days ago, see link. And both webkit and mozilla engines have prefix (-moz -webkit) support for it now. Still badly broken, but progress is finally being made. We should be able to at least make design choices that don't require total rework once writing-mode is more widely available.
Comment 55 Mark A. Hershberger 2011-06-29 19:15:00 UTC
Created attachment 8718 [details]
deonstration of LTR preferences on RTL wiki

Just want to make sure this problem that I just saw on hewiki will be addressed by SPQRobin's work.
Comment 56 Mark A. Hershberger 2011-06-29 19:16:17 UTC
Assigning this to SPQRobin since he has done most of the work.

(In reply to comment #52)
> FYI, rtl and ltr are fun, but are we also at least design wise preparing a bit
> for the next storm, which would be writing-mode ?
> 
> http://dev.w3.org/csswg/css3-writing-modes/
> 
> Needed for traditional Mongolian for instance which uses: top to bottom , left
> to right.

Could you open a separate bug to track this issue?
Comment 57 Robin Pepermans (SPQRobin) 2011-07-06 02:59:17 UTC
Made $wgBetterDirectionality default in core in r91518.

Marking as fixed.

(The only issue left is that the implementation of page language should be improved, see e.g. comment 49, but that's more relevant to bug 28970. Plus, I want to close this bug :p).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links