pablo wrote:

patch for Bidi separation between layout and content

attachment mediawiki-1.7svn-BiDi.patch ignored as obsolete

pablo wrote:

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

attachment mediawiki-1.7svn-BiDi.patch ignored as obsolete

pablo wrote:

*** Bug 4124 has been marked as a duplicate of this bug. ***

pablo wrote:

*** Bug 4102 has been marked as a duplicate of this bug. ***

pablo wrote:

*** Bug 4066 has been marked as a duplicate of this bug. ***

pablo wrote:

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

attachment mediawiki-1.7svn.patch ignored as obsolete

pablo wrote:

*** Bug 4236 has been marked as a duplicate of this bug. ***

pablo wrote:

*** Bug 4953 has been marked as a duplicate of this bug. ***

pablo wrote:

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.

attachment mediawiki-1.7svn.patch ignored as obsolete

pablo wrote:

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

Attached:

rotemliss wrote:

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.

rotemliss wrote:

Problem Screenshot

The bullets are improperly aligned, and the personal bar (above, the user name,
talk page, etc.) is reversed.

Attached:

rotemliss wrote:

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

rotemliss wrote:

Patch to fix the problem

I think this patch will fix the problem.

Attached:

rotemliss wrote:

By the way, the patch must be commited today, else all the RTL wikis will be broken.

rotemliss wrote:

Applied to r14496 by nikerabbit. Thanks.

rotemliss wrote:

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.

Attached:

pablo wrote:

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)

pablo wrote:

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

Attached:

rotemliss wrote:

*** Bug 6756 has been marked as a duplicate of this bug. ***

rotemliss wrote:

*** Bug 6756 has been marked as a duplicate of this bug. ***

rotemliss wrote:

*** Bug 9137 has been marked as a duplicate of this bug. ***

pablo wrote:

It seems the patch hasn't been applied?
What was the problem? it worked very nicely.

ayg wrote:

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.

ayg wrote:

Committed the user login template changes in improved form, r25705. I plan to look at the broader issue later.

ayg wrote:

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.

Attached:

ayg wrote:

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.

Attached:

ayg wrote:

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.

ayg wrote:

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

Attached:

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