[RTL] Need a better way to control the statusbar direction

RESOLVED FIXED

Status

()

Firefox
General
RESOLVED FIXED
10 years ago
8 years ago

People

(Reporter: tomer, Assigned: tomer)

Tracking

(Blocks: 1 bug, {intl, rtl})

Trunk
intl, rtl
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Assignee)

Description

10 years ago
Created attachment 287123 [details]
Current broken Minefield LTR status bar (screenshot with caption)

Text in Hebrew Minefield apper wrong in the status bar due to the fact that we want it to be LTR for URLs but RTL for Status text "Waiting for...". 

Previous versions has #statusbar-display{
direction: ltr !important;} in intl.css, but this seem to break the status messages.

Comment 1

10 years ago
Moving over a flock of granparadiso RTL bugs to Firefox for triage.
Component: he-IL / Hebrew → General
Keywords: intl
Product: Mozilla Localizations → Firefox
Version: unspecified → Trunk
I see that the Persian localization [1] solves this by inserting bidi embedding controls in the localized strings, e.g. 

[RLE]TRANSFERRING DATA FROM [LRE]%1$S[PDF]...[PDF]

[1] http://mxr.mozilla.org/l10n/source/fa/netwerk/necko.properties

Axel, is it possible to mix UTF-8 and escapes (\u202a etc.) in properties files rather than using invisible characters, which make life very difficult when editing?

Comment 3

10 years ago
Unicode escapes still work, and will remain to work in .properties files.
(Assignee)

Comment 4

10 years ago
Any solution for this issue, or we'll have to do the same *workaround* the Persians did?
I think the workaround is actually the most practical solution here.
QA Contact: hebrew.he → general

Updated

10 years ago
Blocks: 412273
(Assignee)

Updated

10 years ago
Blocks: 415606

Updated

10 years ago
Blocks: 415597

Updated

10 years ago
No longer blocks: 412273

Comment 6

10 years ago
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
(Assignee)

Comment 7

10 years ago
Created attachment 321418 [details]
necko.properties with RLE/LRE..PDF
(Assignee)

Comment 8

10 years ago
Created attachment 321419 [details]
necko.properties with RLE/LRE..PDF

Some extra whitespaces removed.
Attachment #321418 - Attachment is obsolete: true
(Assignee)

Comment 9

10 years ago
Created attachment 321420 [details] [diff] [review]
patch

This is very important fix we should get fixed before going final, as it is visually appear on every request.
Assignee: nobody → tomer
Status: NEW → ASSIGNED
Attachment #321420 - Flags: approval1.9?
(Assignee)

Comment 10

10 years ago
I've added /l10n/he/netwerk/necko.properties into the patch of bug 433777 attachment 321801 [details] [diff] [review]. 

ar people - You might wish to do the same in your locale. 
http://mxr.mozilla.org/l10n/source/ar/netwerk/necko.properties
Depends on: 433777

Comment 11

10 years ago
This has been reported in launchpad as well 
https://bugs.edge.launchpad.net/ubuntu/+source/firefox-3.0/+bug/234029
(Assignee)

Comment 12

10 years ago
fixed and landed for 'he'. 
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Updated

10 years ago
Blocks: 412273

Updated

9 years ago
No longer blocks: 415597

Updated

9 years ago
Blocks: 285718
(Assignee)

Comment 13

8 years ago
As Firefox 4 is around the corner, I'd suggest reopening this bug in order to find a better way to do it, as RLE..PDF is not the expected solution.

Updated

8 years ago
Duplicate of this bug: 477189

Updated

8 years ago
You need to log in before you can comment on or make changes to this bug.