Page MenuHomePhabricator

Upload wizard: RTL support is incomplete
Closed, ResolvedPublic

Description

RTL support needs to be completed - aligning text right & change layout for arrows etc.


Version: unspecified
Severity: normal

Details

Reference
bz24692

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 11:03 PM
bzimport added projects: UploadWizard, I18n.
bzimport set Reference to bz24692.

neilk wrote:

We are now using Resource Loader, so we get a lot of RTL for free. It's possible for English readers to test this by setting $wgLanguageCode to 'enrtl'.

What's buggy, first pass:

0 - issue with Resource Loader -- it ONLY responds to $wgLanguageCode; in other words the entire wiki has to be set to use an RTL language. That works fine for Wikipedia but what about Commons? So, we can make it work with RTL but it won't be deployable on Commons?

See related resource loader bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=28228

1 - the arrow progress thing at the top of the page is messed up. Probably a matter of flipping some images and fixing CSS.

2 - for some reason, the "$1 of $2 files uploaded" message is rendered as "of $2 files uploaded $1"

Otherwise it looks like it actually works. Here are Trevor's notes about how to RTLify things:

  • snip ------

Basically there's 3 things to know about RL's RTL handling other than "it's like magic!".

  1. /* @noflip */ means don't flip this.

You can use it on either an entire rule or a single property.

  1. url(icon-ltr.png) becomes url(icon-rtl.png)

This is because we use the "--swap_ltr_rtl_in_url" option. We don't use the "--swap_left_right_in_url" though. So if your images are named accordingly, you will be all set. CSSJanus looks for "ltr" and "rtl" preceded by a word boundary, so turtle.png is safe, but tu.rtle.png is going to become tu.ltre.png.

  1. When using /* @noflip */ together with prefixing the selector with "body.rtl" you can write an RTL only CSS rule without worrying about it applying to LTR or having to write it backwards because it's going to get flipped for you.

You can play with CSSJanus here: http://cssjanus.commoner.com/

  • Trevor
  • snip ------

neilk wrote:

Since we can't actually fix this in a way that works for commons until RL is fixed, marking this as UploadWizard 1.1 and blocking on bug 28228

Issue 0 is fixed in trunk. Issue 3 depended on that (the direction for RTL languages was LTR, causing the text to think it should align the $1 at the other end... a usual issue for bi-directional stuff).

The only issue left in trunk are the arrows at the top (issue 1).

However, a strange thing occurs.. When loading the special page with certain RTL languages, it fails to load anything.. The languages are Yiddish (yi), Arabic (ar) and maybe more. For example Farsi (fa), Hebrew (he) and Urdu (ur) work.

E.g. http://commons.wikimedia.org/wiki/Special:UploadWizard?uselang=ar fails to load for me (on trunk on my localhost as well).

I fixed the arrow thing in r91525. This bug can be closed, but I'd like to have comment 4 confirmed/fixed...

neilk wrote:

@SPQRobin: I see that you added in those rtl & ltr links -- thanks! However something else seems to be broken when I try it with uselang=he. Unless I misunderstand this fix -- should it work with uselang?

Neil, can you give me the complete URL of the site where you are testing? I'll test it and say how broken it is.

I wanted to test it on trunk but UploadWizard doesn't load at all :-/

(Btw, it should give an error an not try to load eternally. Maybe I should submit that as a different bug.)

To answer your question, everything should work on &uselang as well (there are no differences with how the language preference works).

neilk wrote:

(In reply to comment #8)

I wanted to test it on trunk but UploadWizard doesn't load at all :-/

(Btw, it should give an error an not try to load eternally. Maybe I should
submit that as a different bug.)

Generally we don't optimize for the cases when it's broken... :) But I can maybe improve that a bit.

Anyway if you were testing in Hebrew or Arabic (like I was) that might be related to different bugs. There's an issue in the jquery ui calendar for hebrew & a string in arabic is broken. Working on it.

Niel, what's the status of comment 10? (I assume it's fixed?)

neilk wrote:

Some issues I discussed with Amir, just wanted to capture them here.

Tutorial page:

  • the "workflow bar" under title --> LTR
  • checkbox at left
    • next button should be on other side
  • subtitle - no space between message & feedback link
  • white space preceding (at right of) subtitle

neilk wrote:

(In reply to comment #11)

Niel, what's the status of comment 10? (I assume it's fixed?)

Calendar seems to load in Hebrew, but the names of the weekdays look suspect to me (is it normal to label the workdays by "a".."f" then Shabbas? Calendar also has Sunday and Saturday on opposite sides of calendar, is that normal for Hebrew speakers?

In Arabic, looks okay, and week starts with Saturday then Sunday. I believe this is correct?

I don't know what the right thing is for Farsi at all. It may or may not be right

(In reply to comment #13)

Calendar seems to load in Hebrew, but the names of the weekdays look suspect to
me (is it normal to label the workdays by "a".."f" then Shabbas? Calendar also
has Sunday and Saturday on opposite sides of calendar, is that normal for
Hebrew speakers?

Looks the same as Google Calendar in Hebrew (though they abbreviate Shabbat as just 'ש'); work week in Israel begins Sunday and I believe it's customary to do layout with the workdays first, then Friday and Saturday at the end (as many European calendars show Mon-Fri, then Sat/Sun at end).

(In reply to comment #13)

(In reply to comment #11)

Niel, what's the status of comment 10? (I assume it's fixed?)

Calendar seems to load in Hebrew, but the names of the weekdays look suspect to
me (is it normal to label the workdays by "a".."f" then Shabbas? Calendar also
has Sunday and Saturday on opposite sides of calendar, is that normal for
Hebrew speakers?

That is mostly normal, although if one-letter codes are used for weekdays, one letter should be used for Saturday, too. But that's a minor problem.

In Arabic, looks okay, and week starts with Saturday then Sunday. I believe
this is correct?

This is OK. I did find a translation problem there and asked Meno25 to fix it.

I checked Persian and it seems fine, too.

Another little problem is that the category field is a bit too wide and the left border is not seen (Firefox Aurora on Windows XP).

Created attachment 9086
upload wizard - the category field is a bit too wide and the left border is not seen (Firefox Aurora on Windows XP)

Attached:

upload-wizard-RTL-category-field.png (538×911 px, 43 KB)

(In reply to comment #17)

Created attachment 9086 [details]
upload wizard - the category field is a bit too wide and the left border is not
seen (Firefox Aurora on Windows XP)

Is that on current commons.wikimedia.org? I see the same thing there in Firefox 6.0.2 / Ubuntu 11.04, but not on a current trunk checkout: the thumbnail appears on the right, not the left, and I don't see the cut off fields on the left side.

Attached:

upload-wizard-RTL-category-field.png (538×911 px, 43 KB)

(In reply to comment #18)

Is that on current commons.wikimedia.org?

Yes. (That's where i looked with Neil earlier.)

Hi,
3 minor bug in Persian version in commons.
1-calendar
1-1-ي==>ی
1-2-قبلي==>قبلی
1-3-بعدي==>بعدی
2-left line of file title's (*عنوان) text box Bondy in Firefox6 and chrome 13 in winxp doesn't show.
3-bugs of comment 12

suggestion,
why none of wizard's pages doesn't have back button?

Hi,
in RTL language like(ar,fa,..) calendar is inactive.

habibikoolaie wrote:

Reza1615 are true professionals.
Please enable also enabled in the wiki Mzn.

the bugs in comment 20 are solved except calendar. only problem is it doesn't support Fair Use and we can use Old version when we want upload Fair Use Media.

(In reply to comment #23)

the bugs in comment 20 are solved except calendar. only problem is it doesn't
support Fair Use and we can use Old version when we want upload Fair Use Media.

Please do not mix issues; it's confusing to developers. If you want to have "Fair use" added as a license option in the UploadWizard, please create a separate issue. It has nothing to do with RTL support in Upload Wizard.

The calendar issue should probably also be tracked as a separate issue, because that doesn't appear to be an RTL issue to me, but a fairly severe separate issue that surfaces only in particular setups (presumably MediaWiki instances that have an RTL content language).

Probably resolved, but Amir is going to check.

OsamaK.WFM wrote:

A minor tweak for RTL layout would be to change "margin-right: 0.5em" of the "Thanks for using our new upload tool!" message to ""margin-left: 0.5em""

(In reply to comment #26)

A minor tweak for RTL layout would be to change "margin-right: 0.5em" of the
"Thanks for using our new upload tool!" message to ""margin-left: 0.5em""

That's because it's inline css and consequently not flipped. I moved it to the css file in r111665.

Calendar works for me in RTL.

I fixed an arrow pointing the wrong way in https://gerrit.wikimedia.org/r/3891 .

After that patch is reviewed this bug can probably marked as fixed.

would you please edit Calendar form labels from Arabic charters to Farsi characters?
1-ي==>ی
2-قبلي==>قبلی
3-بعدي==>بعدی

(In reply to comment #29)

would you please edit Calendar form labels from Arabic charters to Farsi
characters?
1-ي==>ی
2-قبلي==>قبلی
3-بعدي==>بعدی

These are part of the localization of the datepicker, which is a separate component. And it's a translation mistake and not a right-to-left issue.

Can you please open a separate bug about it?

(In reply to comment #30)

(In reply to comment #29)

would you please edit Calendar form labels from Arabic charters to Farsi
characters?
1-ي==>ی
2-قبلي==>قبلی
3-بعدي==>بعدی

These are part of the localization of the datepicker, which is a separate
component. And it's a translation mistake and not a right-to-left issue.

Can you please open a separate bug about it?

bug 35579

Thank you, reza1615. I edited that bug accordingly.

The last patch was applied :)

I proclaim the UploadWizard's RTL support complete.

The checkbox on the bottom of first page is left-aligned, it should be right-aligned. Also, the text in the tab labels is not centered in the label (it is in English version) these are minor but bug 31070 depends on them!

(In reply to comment #34)

The checkbox on the bottom of first page is left-aligned, it should be
right-aligned.

Which checkbox? "Skip this step in the future"? It is place near the "Next" button, which is on the left in RTL and on the right in LTR. This makes sense to me.

Also, the text in the tab labels is not centered in the label

What text? Learn, Upload, Release rights, Describe, Use? Looks centered to me in English and Persian.

I am testing in Firefox, and it works both on my testing wiki and on Commons.

If I misunderstand something or if you use a different browser, let me know.

Also, can you upload a screenshot?

Created attachment 11553
I added compression screenshot en vis fa veiw

Attached:

02.png (762×964 px, 65 KB)

Oh I see - it's kinda in the center, but not exactly: some padding is added to make it look better, but always on the right side. I adjusted it for RTL:
https://gerrit.wikimedia.org/r/#/c/39831/

Valerie.m.juarez wrote:

It looks like the labels are centered now. Reza, how does the checkbox look?

Can we close this bug?

Alright, I finally got the time to test Upload Wizard in Persian on Commons.

<<Learn>>
The font is wrong. It should use the same font that the is used by the rest of the interface. Part of the upload wizard does (for example, the "Skip this step in the future" does, but the "Next" button doesn't, see here: https://commons.wikimedia.org/wiki/File:Font-Issue-Bug-24692.png

Similarly, the top tabs (learn, upload, ...) are using a font other than the one used by the rest of the interface.

<<Upload>>
The "select file" button uses the wrong font.

Once upload is finished, the "All uploads were successful!" message needs margin-left (or the button after it, needs margin-right). The text and the button touch each other right now.

<<Release rights>>
The translation of "Use a different license" must be left-aligned, to mirror the LTR interface. It is now right-aligned in both LTR and RTL interfaces.

<<Describe>>
The translation of "This entry is too short. Please make this entry longer than X characters." uses a non-localized number in place for X. It should use localized numbers.

Huji, would you be kind enough to open separate bugs for these issues? They can be blockers of this one. It will be more convenient for me to get to them one by one. Thanks.

(In reply to comment #39)

Alright, I finally got the time to test Upload Wizard in Persian on Commons.

<<Learn>>
The font is wrong. It should use the same font that the is used by the rest
of
the interface. Part of the upload wizard does (for example, the "Skip this
step
in the future" does, but the "Next" button doesn't, see here:
https://commons.wikimedia.org/wiki/File:Font-Issue-Bug-24692.png

Similarly, the top tabs (learn, upload, ...) are using a font other than the
one used by the rest of the interface.

<<Upload>>
The "select file" button uses the wrong font.

https://commons.wikimedia.org/w/index.php?title=MediaWiki%3ACommon.css&diff=86606637&oldid=83346857 cause this bug! and in test wiki it is ok.

Once upload is finished, the "All uploads were successful!" message needs
margin-left (or the button after it, needs margin-right). The text and the
button touch each other right now.

<<Release rights>>
The translation of "Use a different license" must be left-aligned, to mirror
the LTR interface. It is now right-aligned in both LTR and RTL interfaces.

<<Describe>>
The translation of "This entry is too short. Please make this entry longer
than
X characters." uses a non-localized number in place for X. It should use
localized numbers.

@Amir now the only bug id wrong directions :)

Huji: Please file seperate bug reports for the issues in comment 39, if they still appear.

Closing as FIXED as all patches have been merged and only minor followup things might need to get fixed (non-centered text or using a different font is NOT "incomplete RTL support" especially as fonts are language-specific, not RTL-generic).

Gilles raised the priority of this task from High to Unbreak Now!.Dec 4 2014, 10:11 AM
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to High.Dec 4 2014, 11:21 AM