Closed
Bug 846595
Opened 11 years ago
Closed 10 years ago
[Building Blocks][RTL] Value selector tick should be aligned left for right-to-left languages (i.e. Arabic)
Categories
(Firefox OS Graveyard :: Gaia, defect)
Tracking
(b2g18?, b2g-v2.2 verified)
VERIFIED
FIXED
People
(Reporter: gkw, Assigned: mihai)
References
Details
(Keywords: b2g-testdriver, l12y, unagi, Whiteboard: l10n)
Attachments
(4 files)
Git commit info: 2013-02-22 11:01:05 5691a16fff8e1403c75ed9d6f3a443b7... Go to Settings -> Device Information -> More Information -> Developer -> Launch first time use. By default, English should be selected. Select the first option (Arabic), and wait a moment for the language to change. Problem 1: You can see that the tick sits on top of the Arabic word. Problem 2: Scroll down to see that the entry for English is "(English (US" - the parentheses are wrong here. The same goes for Brazilian Portuguese and Simplified Chinese. Now switch back to English and press Next. Problem 3: Some of the entries in the Wi-Fi list are still listed in Arabic. This was found using the script in bug 832328. Credits also go out to cjones and gwagner. Setting this to major as this impacts the first impression that people have of Firefox OS phones.
Reporter | ||
Comment 1•11 years ago
|
||
Reporter | ||
Comment 2•11 years ago
|
||
Note that for problem 3 to occur, one should have switched to Arabic, hit Next to the Wi-Fi screen in Arabic, hit back to the language select menu, select English, then hit Next to the Wi-Fi screen in English again.
Updated•11 years ago
|
Component: General → Gaia::First Time Experience
Updated•11 years ago
|
QA Contact: lebedel.delphine
Comment 3•11 years ago
|
||
Reproducible on Unagi, v1 pvt nightly build: Gaia d90ee5a412116f4f1f2e43b6c60700de5923513e BuildID 20130304070201 Version 18.0 I don't even get anything to appear under wifi in Problem 3. Should these be filed separately under 3 different bugs maybe?
Reporter | ||
Comment 4•11 years ago
|
||
> Should these be filed separately under 3 different bugs maybe? I've cloned this bug into bug 847739 (problem 2) and bug 847740 (problem 3), and also morphed this bug to problem 1.
Summary: RTL issues in First Time Experience → In First Time Experience, tick sits on top of the Arabic language option when Arabic is selected
Comment 5•11 years ago
|
||
Does this happen for languages that are used in v1 target markets?
Comment 6•11 years ago
|
||
yes
Comment 7•11 years ago
|
||
I mean "no". Got confused between your actual question and the fact that the bug appeared on the words English and Portuguese... So, no.
Comment 8•11 years ago
|
||
(In reply to delphine from comment #7) > I mean "no". > Got confused between your actual question and the fact that the bug appeared > on the words English and Portuguese... > So, no. Sorry, now I'm confused :) Modifying Gary's STR from comment 0: 1. Go to Settings -> Device Information -> More Information -> Developer -> Launch first time use 2. English should be selected, select Portuguese and wait a moment for the language to change. Does the language selection checkmark sit on top of the Portuguese word?
Flags: needinfo?(lebedel.delphine)
Reporter | ||
Comment 9•11 years ago
|
||
> Does the language selection checkmark sit on top of the Portuguese word?
No it doesn't. The probable reason this affects Arabic is because Arabic is RTL (right to left), but Portuguese is not.
Moreover I still think that this bug is really easy to hit, even in target markets.
If I'm a Portuguese user, I may accidentally hit the top line (Arabic). Give it a second or two and it switches to Arabic and the bug is noticed.
Comment 10•11 years ago
|
||
We're not going to have Arabic on the shipped devices, though. That language is only part of the builds for RTL testing, not for release testing.
Reporter | ||
Comment 11•11 years ago
|
||
(In reply to Axel Hecht [:Pike] from comment #10) > We're not going to have Arabic on the shipped devices, though. That language > is only part of the builds for RTL testing, not for release testing. Ah, ok. Now that makes sense then.
Updated•11 years ago
|
Flags: needinfo?(lebedel.delphine)
Comment 12•11 years ago
|
||
Not tracking since this is not a shipping language - assuming that the non-shipping languages are being tracked in another bug for removal from shipped locales.
Comment 13•11 years ago
|
||
We have the same issue with our <select> implementation in Gaia.
Assignee | ||
Comment 14•11 years ago
|
||
Added padding rules for the list labels in the ftu/style.css
Attachment #740364 -
Flags: review?(fbsc)
Comment 15•11 years ago
|
||
Hi Mihai! Im gonna move this to arnau, because probably this should be fixed globally. Thanks!
Comment 16•11 years ago
|
||
Comment on attachment 740364 [details]
Pull Request #9343 - Fix tick icon overlaying label text
Moving to Arnau, due to probably could be fixed as part of Building Blocks.
Attachment #740364 -
Flags: review?(fbsc) → review?(arnau)
Mihai, to tell you the truth I have no idea how the UI should behave in RTL, either your solution or left aligning the icon. This is something I would like to discuss with the visual team. Adding Sergi to this thread.
Assignee | ||
Comment 18•11 years ago
|
||
(In reply to arnau from comment #17) > Mihai, to tell you the truth I have no idea how the UI should behave in RTL, > either your solution or left aligning the icon. This is something I would > like to discuss with the visual team. Adding Sergi to this thread. Hi Arnau, let me know once a decision is made on this. Other list elements (i.e. Language selection from Settings app) treat the tick as I implemented it for this bug: always right hand side, but not overlapping the text label.
Assignee: nobody → mihai
Comment 19•11 years ago
|
||
Hi guys, we've not designed the UI to support languages which are written from right to left. As i've read up in this thread arabic is not supposed to be supported. Anyway my suggestion is to align the tick to the left leaving the same padding it has when aligned to the right. Anyway this is a temporary patch from a visual point of view, and the UI should be entirely reviewed if we're supposed to support these languages (which AFAIK is not in the roadmap).
Assignee | ||
Comment 20•11 years ago
|
||
(In reply to Sergi from comment #19) > Hi guys, we've not designed the UI to support languages which are written > from right to left. As i've read up in this thread arabic is not supposed to > be supported. Anyway my suggestion is to align the tick to the left leaving > the same padding it has when aligned to the right. > > Anyway this is a temporary patch from a visual point of view, and the UI > should be entirely reviewed if we're supposed to support these languages > (which AFAIK is not in the roadmap). Hi Sergi, thanks for your feedback. Your suggestion to align the tick to the left (leaving the same padding it had when aligned to the left) would need to be included in all other list types (i.e. select) for consistency. The current implementation for other lists is to keep the tick on the right, but not overlap text label (which only happens in the FTU). I know RTL languages are not in the roadmap yet, but if the desired UX is as you mentioned it, I can convert this bug to treat all list types with the expected behavior: tick aligned left, and have this bug solved for future versions.
Flags: needinfo?(sergiov)
Comment 21•11 years ago
|
||
(In reply to Mihai Cirlanaru [:mcirlanaru] from comment #20) > (In reply to Sergi from comment #19) > > Hi guys, we've not designed the UI to support languages which are written > > from right to left. As i've read up in this thread arabic is not supposed to > > be supported. Anyway my suggestion is to align the tick to the left leaving > > the same padding it has when aligned to the right. > > > > Anyway this is a temporary patch from a visual point of view, and the UI > > should be entirely reviewed if we're supposed to support these languages > > (which AFAIK is not in the roadmap). > > Hi Sergi, thanks for your feedback. > > Your suggestion to align the tick to the left (leaving the same padding it > had when aligned to the left) would need to be included in all other list > types (i.e. select) for consistency. The current implementation for other > lists is to keep the tick on the right, but not overlap text label (which > only happens in the FTU). > > I know RTL languages are not in the roadmap yet, but if the desired UX is as > you mentioned it, I can convert this bug to treat all list types with the > expected behavior: tick aligned left, and have this bug solved for future > versions. yes, i think that's the best approach at the moment. Thanks!
Flags: needinfo?(sergiov)
Assignee | ||
Comment 22•11 years ago
|
||
Thanks for confirming this, Sergi. I updated the bug's summary to tackle value selectors in general for RTL languages. Requesting tracking-b2g18 since the patch for this would provide a consistent UX for value selectors when RTL languages (e.g. Arabic, Hebrew) will be considered.
Summary: In First Time Experience, tick sits on top of the Arabic language option when Arabic is selected → [Building Blocks][RTL] Value selector tick should be aligned left for right-to-left languages (i.e. Arabic)
Assignee | ||
Comment 23•11 years ago
|
||
One thing that came to my mind: should the tick be mirrored when aligned left?
Severity: major → normal
Component: Gaia::First Time Experience → Gaia
Flags: needinfo?(sergiov)
Assignee | ||
Updated•11 years ago
|
Attachment #740364 -
Flags: review?(arnau)
Comment 24•11 years ago
|
||
(In reply to Mihai Cirlanaru [:mcirlanaru] from comment #23) > One thing that came to my mind: should the tick be mirrored when aligned > left? I'd say no. We should place it to the left, but not mirroring it.
Flags: needinfo?(sergiov)
Reporter | ||
Updated•11 years ago
|
Updated•11 years ago
|
No longer blocks: fxos-papercuts
Assignee | ||
Comment 25•10 years ago
|
||
Comment on attachment 740364 [details] Pull Request #9343 - Fix tick icon overlaying label text A while ago I started working on this but stopped since the BB were within the System app. Now, since that is sorted, I have updated the PR based on the suggestion from comment 19. Arnau, let me know if it looks good.
Attachment #740364 -
Flags: review?(arnau)
Comment on attachment 740364 [details]
Pull Request #9343 - Fix tick icon overlaying label text
Mihai, you can merge as soon as you fix some small nits commented in github.
Thanks!
Attachment #740364 -
Flags: review?(arnau) → review+
Assignee | ||
Comment 27•10 years ago
|
||
Thanks Arnau! Landed on master: https://github.com/mozilla-b2g/gaia/commit/c8e6e9fdaee8142aad9ea7f8faef4d974e28c54d
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
Whiteboard: [rtl-meta] → [rtl-meta]l10n
QA Whiteboard: [rtl-impact]
Whiteboard: [rtl-meta]l10n → l10n
Comment 30•9 years ago
|
||
This issue Verified successfully on flame 2.2: Gaia-Rev f5b3d1b6cfa3e702033f613915ae637cb735cbfb Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/bccee1a13ba6 Build-ID 20150119002502 Version 37.0a2 Device-Name flame FW-Release 4.4.2 Rproduce rate 0/5 Refer to video VIDEO0263_Compress.MP4
status-b2g-v2.2:
--- → verified
Keywords: verifyme
Comment 31•9 years ago
|
||
Comment 32•9 years ago
|
||
Test case has been added in moztrap: https://moztrap.mozilla.org/manage/case/15448/
Flags: in-moztrap+
This bug is verified fixed on Flame 3.0 1) The tick mark is properly placed on the left side 2) Parenthesis are properly fitted around the "US" 3) When switching back to English, all text is translated back to English Environmental Variables: Device: Flame 3.0 (319mb)(Kitkat)(Full Flash) Build ID: 20150205010209 Gaia: 2b83a6d5d1185a438b5bbd287497ac2743b501db Gecko: 34a66aaaca81 Gonk: e7c90613521145db090dd24147afd5ceb5703190 Version: 38.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [rtl-impact] → [QAnalyst-Triage?][rtl-impact]
Flags: needinfo?(pbylenga)
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?][rtl-impact] → [QAnalyst-Triage+][rtl-impact]
Flags: needinfo?(pbylenga)
You need to log in
before you can comment on or make changes to this bug.
Description
•