486824 - [RTL] Software update screen should get RTL support

Status: RESOLVED FIXED

(Mozilla Localizations :: he / Hebrew, defect)

Description

[Tomer Cohen :tomer]

Attachment: Current result (screenshot)

The Software Update screen, which appear for few seconds while applying updates to Firefox core before the browser starts doesn't have any way to declare it as a RTL window, and this may cause display issues for RTL locales. 

Currently, the message appear as "Firefox is installing your updates...", while for Hebrew (and probably other RTL locales!) we are getting it as "is installing your updates... Firefox" due to the lack of dir=rtl. 

Since it might be a problem to add RTL to this window as it is not native XUL window, we can only add some hacks to our translations. I've tested it and adding RLE at the start of the string is enough for showing the message right.


Steps to reproduce:
bug 357358 should help us creating a fake software update, but I must admit I didn't find how to use it.

Here is how I did it - 

1. Make sure you have previously applied update in updates/0. 
2. Change the status of updates/0/update.status from "succeed" to "pending".
3. Make the changes in updater.ini.
4. Launch Firefox again and watch the string before it gone (up to few seconds, don't blink).

Comment 1

[Tomer Cohen :tomer]

Attachment: Patch applied for 'he'.

I have added RLE (u+202B) to the string InfoText in he/browser/updater/updater.ini, right between the equal characters and the percents sign. Doing this force the string to appear as RTL, even as the first character is in English.

Ehsan, Anas - I have CCed both of you, as you may want to do something similar in your locales.

Comment 2

[(no longer active)]

Thanks for finding this bug and coming up with its fix! :-)

I applied the fix to fa.

Comment 3

[Simon Montagu :smontagu]

The ideologically sound way to fix this would be as in bug 406088 for crash reporter. However, I doubt if it's worth the investment if the only UI is what appears in the screenshot here.

What happens with the progress meter? Does it always move from left to right?

Comment 4

[(not currently active) Ted Mielczarek]

So, since the updater is a native app like the crashreporter let me present the difficulty level of doing it per-platform:
1) GTK: easy, just requires a call to gtk_widget_set_default_direction on RTL l10ns:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/client/crashreporter_linux.cpp#597
2) OS X: moderate, need to create a separate NIB with RTL layout, and selectively load one or the other:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/client/crashreporter_osx.mm#763
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/client/macbuild/Contents/Resources/English.lproj/
3) Win32: hard, need to tweak the dialog box resource in-memory using a struct that's not defined in header files:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/client/crashreporter_win.cpp#832

Comment 5

[(no longer active)]

(In reply to comment #3)
> The ideologically sound way to fix this would be as in bug 406088 for crash
> reporter. However, I doubt if it's worth the investment if the only UI is what
> appears in the screenshot here.

I don't think this is worth investing the time, since it's only one string inside the window, and the solution that Tomer presented works correctly as far as users are concerned.

> What happens with the progress meter? Does it always move from left to right?

Yes, even in XUL widgets the progress meter moves from left to right.  And that is the same way that things like the video progress bar behave.

Comment 6

[(no longer active)]

(In reply to comment #4)
> 3) Win32: hard, need to tweak the dialog box resource in-memory using a struct
> that's not defined in header files:
> http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/client/crashreporter_win.cpp#832

Out of curiosity, wouldn't SetWindowLong with WS_EX_LAYOUTRTL work without going through those hoops?

Check out this page for reference: <http://msdn.microsoft.com/en-us/library/aa913269.aspx>

Comment 7

[(not currently active) Ted Mielczarek]

I am fairly certain that I tried that, and it doesn't take effect when used with SetWindowLong, and since it's a dialog, you can't pass it via CreateWindow either.

Comment 8

[Anas Husseini [:linostar]]

I wonder if this affect Arabic because we transliterate the word 'Firefox' and write it in Arabic letters, so ideally we don't need to add an RLE character (please correct me if I'm mistaken).

Comment 9

[(no longer active)]

(In reply to comment #8)
> I wonder if this affect Arabic because we transliterate the word 'Firefox' and
> write it in Arabic letters, so ideally we don't need to add an RLE character
> (please correct me if I'm mistaken).

%MOZ_APP_DISPLAYNAME% will be selected by the build system as something like "Firefox", "Shiretoko" or "Minefield", and I don't think that name is localizable.  So I believe that the Arabic build will also use an English name in that window, so it would need this trick as well.

You can verify this by opening the updater.ini file in an Arabic build.

Comment 10

[Tomer Cohen :tomer]

I have copied the same file over to he/mail/updater/updater.ini and he/calendar/updater/updater.ini. 

Ehsan, Anas - you may want to follow.

Comment 11

[(no longer active)]

(In reply to comment #10)
> I have copied the same file over to he/mail/updater/updater.ini and
> he/calendar/updater/updater.ini. 
> 
> Ehsan, Anas - you may want to follow.

Thanks, done for Persian.

Comment 12

[Anas Husseini [:linostar]]

Done for Arabic in mail/ and fx32/browser/.