Last modified: 2012-04-19 21:10:42 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
Created attachment 1835 [details] patch for Bidi separation between layout and content
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
*** Bug 4124 has been marked as a duplicate of this bug. ***
*** Bug 4102 has been marked as a duplicate of this bug. ***
*** Bug 4066 has been marked as a duplicate of this bug. ***
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
*** Bug 4236 has been marked as a duplicate of this bug. ***
*** Bug 4953 has been marked as a duplicate of this bug. ***
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.
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
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.
Created attachment 1863 [details] Problem Screenshot The bullets are improperly aligned, and the personal bar (above, the user name, talk page, etc.) is reversed.
(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.
Created attachment 1864 [details] Patch to fix the problem I think this patch will fix the problem.
By the way, the patch must be commited today, else all the RTL wikis will be broken.
Applied to r14496 by nikerabbit. Thanks.
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.
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)
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
*** Bug 6756 has been marked as a duplicate of this bug. ***
*** Bug 9137 has been marked as a duplicate of this bug. ***
It seems the patch hasn't been applied? What was the problem? it worked very nicely.
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.
Committed the user login template changes in improved form, r25705. I plan to look at the broader issue later.
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.
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.
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.
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.
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.
*** Bug 19228 has been marked as a duplicate of this bug. ***
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.
*** Bug 4067 has been marked as a duplicate of this bug. ***
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.
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.
Trevor, talk Amir about how this is needed for Commons.
*** Bug 13447 has been marked as a duplicate of this bug. ***
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.
Wikimedia Incubator needs this functionality too. Its a multilingual wiki.
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
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.
Yes that was the idea with $wgBetterDirectionality but I didn't have time to pursue it further back then.
Marking as enhancement since this is really a new feature.
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"
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
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).
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).
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 :-).
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.
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.).
*** Bug 28228 has been marked as a duplicate of this bug. ***
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.
(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.
@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.
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.
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?
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).
