Amir E. Aharoni wrote:

On Sat, Apr 3, 2010 at 01:05, Roan Kattouw roan.kattouw@gmail.com wrote:

...

2010/4/2 Amir E. Aharoni amir.aharoni@mail.huji.ac.il:

...

Hello, Vector skin specialists,

There are serious RTL (right-to-left) problems with the Vector skin on Commons.

The thing is that the Vector skin outputs different HTML and different CSS based on whether the *content language* of the wiki is LTR or RTL. Commons's content language is English, so Vector will always output RTL HTML/CSS on Commons. The same applies to Monobook, but it so happens LTR Monobook is easier to hack with some CSS so it looks like RTL Monobook.

Certain issues, especially the tab order issue mentioned at http://commons.wikimedia.org/wiki/User_talk:Slomox#The_problem_with_tabs , are lesse easy to hack around. You can probably hack around even that by reordering elements in JS, but we should really just have the ability to show an RTL interface (but LTR content!) when the user language is an RTL language. This was filed ages ago as https://bugzilla.wikimedia.org/show_bug.cgi?id=6100

I already saw that bug and i hope that it will be solved soon. In the meantime i can live without a full-blown RTL Commons, but it's very important that file upload forms will work well and that it will possible to have a basic conversation on a user talk page. (I shall temporarily presume that serious conversations will be in English.)

Many Hebrew-speaking Wikipedians have useful free images to upload, but are intimidated by confusing forms which are either in Legalese-English or in Broken-RTL-Hebrew. Lately i've been translating templates, messages and policy pages there and in the worst case it's possible to set a page to be <div dir="rtl">, but it's more complicated with the forms.

Now it actually seems that the forms are OK, but other important parts of the interface are broken. Do these things have to go together? Is it possible to at least have the forms as they are now and to have the rest of the interface not broken?

Hi, Amir.

When the default interface is switched, the tab navigation on top, the left navigation, and the toolbar will be changed mainly. Forms such as upload forms will not be affected. I see what you mean by how the tab navigation is not lined up properly if your language preference is in RTL. The user experience tech team is looking into how we can improve it.

Thanks,

- Naoko

Marcus Buck wrote:

Mediawiki provides no real support for truly multilingual wikis at all. Despite the fact that the prominent multilingual wikis Commons and Meta are around since 2004 and 2001 respectively. Making Mediawiki truly multilingual is a heavy task. There are at least a dozen things that come up in my mind where Mediawiki sucks multilinguality-wise. But a simple first starting step would be to create a global variable like "$wgMultilingualWiki = true/false" and if it is set to true the content language will automatically be set to the language set in the preferences. That will remove several problems like the wrong tab order for RTL languages or the fact that {{PLURAL: }} doesn't work correctly for any language with a different plural structure than English.

I was going to suggest more or less the same thing. Although I don't think blindly setting $wgContLang = $wgLang is really a good idea -- too many things would break if we did that.

(For example, {{PLURAL:}} really _has_ to be parsed according to the language the page/message is written for, since the meaning of the params varies between languages. What making {{PLURAL:}} useful in multilingual page content really needs is a syntax for specifying the intended language inline. Anyone interested in trying that might want to note that there's a (currently incomplete) ParserFunctions-based reimplementation at http://commons.wikimedia.org/wiki/Template:Plural which tries to do just that.)

It would be better to just look for spots (like LTR/RTL rendering) where that can be safely done and sprinkle them with lines like:

global $wgMultilingual, $wgLang, $wgContLang; $lang = $wgMultilingual ? $wgLang : $wgContLang;

Alternatively, I suppose we could introduce a new global -- say, $wgInterfaceLang -- which could be set to equal either $wgLang or $wgContLang in Setup.php.

Niklas Laxström wrote:

On 3 April 2010 20:53, Ilmari Karonen nospam@vyznev.net wrote:

...

(For example, {{PLURAL:}} really _has_ to be parsed according to the language the page/message is written for, since the meaning of the params varies between languages. What making {{PLURAL:}} useful in multilingual page content really needs is a syntax for specifying the intended language inline.

In my opinion that's the wrong way. We do not want to hack individually the syntax of every language dependent magic word.

There should be a way to tag the language of whole blocks of text and the parser should be made aware of it. We should do the tagging already on the basis that marking up correctly the language of everything is the right thing to do.

Yeah, that would work too.

The easy way, I think, would be with a parser function. Something like {{lang:en|this, for example}}.

Another possibility would be to try and extract lang attributes from HTML tags, but AFAIK this wouldn't fit into the current parser workflow very well -- brace expansion happens long before normal HTML tags (as opposed to special ones like <nowiki>) are even looked at. I could be wrong about that, though.

Also, <span lang="en"></span> takes more effort to type than {{lang:en|}}. :) Although, on the other hand, turning the latter into correct HTML would be somewhat nontrivial, at least unless we want to just replace it with span tags and let Tidy take care of little details like correct nesting.