1217746 - [RTL][Notifications]The unit of the data was displayed at right side of number in notification data limit related bar.

Status: RESOLVED WONTFIX

(Mozilla Localizations :: ar / Arabic, defect, P2)

Description

[SandKing]

Attachment: Bug picture: Aries&Flame_v2.5.png

[1.Description]:
[RTL][Aries KK v2.5][Flame v2.5][Notifications]With device in  "Arabic" language, the unit of the data was displayed at right side of number in notification data limit related bar.
See picture:"Aries&Flame_v2.5.png"

[2.Testing Steps]: 
Precondition: Insert a SIM card.
1. Change system language as "Arabic".
2. Launch "Usage".
3. Enable "Data use alert" and set a upper limit..
4. Pull down notifications and check data limit related UI. 


[3.Expected Result]: 
4.The unit of the data  should be displayed at left side of number

[4.Actual Result]: 
4.The unit of the data was displayed at right side of number

[5.Reproduction build]: 
Device: Flame KK 2.5(Affected) 
Build ID               20151022150207
Gaia Revision          29ce8ec8606e59f582375234440812b046346513
Gaia Date              2015-10-22 05:31:38
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/76bd0c01d72e64ca4f261ffdb2652a91f961e930
Gecko Version          44.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151022.185000
Firmware Date          Thu Oct 22 18:50:13 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Aries KK 2.5 (Affected)
Build ID               20151023005002
Gaia Revision          29ce8ec8606e59f582375234440812b046346513
Gaia Date              2015-10-22 05:31:38
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1f03a14106e59280761ac53904340f389674337f
Gecko Version          44.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151023.001128
Firmware Date          Fri Oct 23 00:11:35 UTC 2015
Bootloader             s1

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]: 
15707

Comment 1

[Augustin Trancart [:autra]]

Not a system issue, but a costcontrol one (this part of the UI is actually a bit of the latter).

Comment 2

[Sam Foster [:sfoster] (he/him)]

I'll take suggestions on how to fix this one? I cant figure out how to get at this widget in the webIDE. Its in an iframe in the utility tray. I'm not sure if this just needs a dir=auto on the #data-limit element in widget.html (tried that didn't seem to work) or if the source of the bug is upstream in how the notification detail is composed and formatted.

Comment 3

[Sam Foster [:sfoster] (he/him)]

Zibi, this is the bug we discussed in #fxos. We're trying to represent a string like "Data Limit (10MB)" and the unit is ending up on the wrong side

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

I'm not expert in RTL, but my sixth sense tells me that `magnitude` entity should be reversed for rtl: http://hg.mozilla.org/gaia-l10n/ar/file/1336a60d3d29/apps/costcontrol/costcontrol.properties#l14

Ahmed, can you confirm?

Comment 5

[Augustin Trancart [:autra]]

Not sure. Inspecting the "magnitude" string shows words order is correct [1].

However, inspecting the string added to the UI shows that there is something wrong [2]: the first FSI force the string inside the parenthesis to have its own direction. As it is starting with a latin number, it takes a LTR direction, thus the wrong order of words. 

There's 2 way of fixing this imho (I've tested both):
- In [2] you can see there is a nested FSI/PDI block around the unit string only. Zibi, these marks are added by l10n, aren't they? Not sure if it is easy to do so, but here, they shouldn't nest and the string should be [3]. But as far as I understand what l10n does here, that might not be easy, and maybe break other cases. WDYT?
- Or we can just add a RTLM (\u200F) in front of the "magnitude" string [4]. This would be the first char in the outer FSI/PDI block and the inner calculated direction would be RTL.

WDYT Ahmed, Zibi?


[1] https://r12a.github.io/uniview/?charlist=%20{{value}}%20{{unit}}#title
[2] https://r12a.github.io/uniview/?charlist=%D8%AD%D9%8E%D8%AF%20%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA%20%28%E2%81%A81.00%20%E2%81%A8%D8%AC.%D8%A8%E2%81%A9%E2%81%A9%29
[3] https://r12a.github.io/uniview/?charlist=%D8%AD%D9%8E%D8%AF%20%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA%20%28%E2%81%A81.00%E2%81%A9%20%E2%81%A8%D8%AC.%D8%A8%E2%81%A9%29
[4] https://r12a.github.io/uniview/?charlist=%20%E2%80%8F{{value}}%20{{unit}}#title

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

> - In [2] you can see there is a nested FSI/PDI block around the unit string only. Zibi, these marks are added by l10n, aren't they? Not sure if it is easy to do so, but here, they shouldn't nest and the string should be [3]. But as far as I understand what l10n does here, that might not be easy, and maybe break other cases. WDYT?

I see what you mean here. Not only do we add FSI/PDI, we do this twice because of how the string is constructed. We wrap each part separately.
Long term solution is to use the currently developed spec for Intl.UnitFormat which will allow us to produce properly formatter unit strings.

For now, I'm afraid that it would be very hard to denote that a single l10n string should not have its variables isolated.

> - Or we can just add a RTLM (\u200F) in front of the "magnitude" string 

That would be easier to try, but not sure how it'll work.

Generally speaking we now have: 

magnitude = 1.00 [FSI]{{unit}}[PDI]
data-limit = ...([FSI]{{magnitude}}[PDI])

which turns into ... ([FSI]1.00 [FSI]{{unit}}[PDI][PDI])

will setting [RLM] in front of magnitude make it work?

Comment 7

[Augustin Trancart [:autra]]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #6)
> 
> > - Or we can just add a RTLM (\u200F) in front of the "magnitude" string 
> 
> That would be easier to try, but not sure how it'll work.

I've already tried, it works (both solution do btw).

> 
> Generally speaking we now have: 
> 
> magnitude = 1.00 [FSI]{{unit}}[PDI]
> data-limit = ...([FSI]{{magnitude}}[PDI])
> 
> which turns into ... ([FSI]1.00 [FSI]{{unit}}[PDI][PDI])
> 
> will setting [RLM] in front of magnitude make it work?

Could we use a column representation like in [1] (this is the solution 2/ I proposed in comment 5)? I find this horizontal LTR representation confusing when we're dealing with LTR/RTL texts :-D


But yeah, If I make it horizontal, and assuming a LTR direction for order in memory, then:
... ([FSI][RLM]1.00 [FSI]{{unit}}[PDI][PDI])
 displays correctly, because the inner direction of the first FSI/PDI block will then be calculated as RTL (the first strong directional char is RTL). Thus, the "words" inside it (so '[RLM]1.00' and '[FSI]{{unit}}PDI')  will be displayed starting from the right (so it would be visually '{{unit}} 1.00')

So, just copy-pasting the string in [1] in costcontrol.properties for magnitude fixes it for me.

[1] https://r12a.github.io/uniview/?charlist=%20%E2%80%8F{{value}}%20{{unit}}#title

Comment 8

[Sam Foster [:sfoster] (he/him)]

Moving to localizations/Arabic, lets use the explicit direction marks as outlined in comment #7

Comment 9

[Khaled Hosny]

We no longer localize FFOS.

For the record, numbers (even European ones) have weak directionality, so “10.00 م.ب“ should resolve to a RTL base direction without needing a manual RLM. So there is/was a BiDi bug somewhere.