Closed Bug 1162432 Opened 10 years ago Closed 10 years ago

[l10n][Settings]Polish:"Show after reboot" is displayed with truncation at "Notifications" view in Settings.

Categories

(Mozilla Localizations :: pl / Polish, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.1 affected, b2g-v2.2 affected)

VERIFIED WONTFIX
Tracking Status
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: yue.xia, Assigned: stef)

References

Details

(Whiteboard: LocRun2.2)

Attachments

(2 files)

Attached image Polish_Show after reboot.png (deleted) —
[1.Description]: [l10n][Flamev2.1&v2.2][Settings]Polish:"Show after reboot" is displayed with truncation at "Notifications" view in Settings. See attachement:Polish_Show after reboot.png [2.Testing Steps]: 1.Set your phone language to Polish. 2.Launch Settings and select "Notifications". [3.Expected Result]: 2."Show after reboot" should not be displayed with truncation. [4.Actual Result]: 2."Show after reboot" is displayed with truncation. [5.Reproduction build]: Device: Flame 2.1 user (Affected) Build ID 20150506001242 Gaia Revision b4a03b7ee61de5a479b3cf0916f47e91a43b0f50 Gaia Date 2015-04-30 21:31:55 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/4493015380ab Gecko Version 34.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150506.035318 Firmware Date Wed May 6 03:53:29 EDT 2015 Bootloader L1TC000118D0 Device: Flame 2.2 user (Affected) Build ID 20150506002501 Gaia Revision 772a9491909abd02dc67278dd453746e2dd358a8 Gaia Date 2015-05-05 02:02:24 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/3af6a0a79227 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150506.040211 Firmware Date Wed May 6 04:02:22 EDT 2015 Bootloader L1TC000118D0 [6.Reproduction Frequency]: Always Recurrence,10/10 [7.TCID]: Free Test
Also in 2.0, as reported in http://bugs.aviary.pl/show_bug.cgi?id=4961 In 3.0 this has been fixed (second line), maybe the fix could be backported? Additional question, why we need so big margin here? I see that checkbox has 15px "margin" on the left (flame) but on the right we set the gap to 6.1rem=61px, https://github.com/mozilla-b2g/gaia/blob/d50d05be5aaf02926d15b626ed8950d703df69d1/apps/settings/style/lists.css#L299 Changing it to be the same on both side wouldn't fix this particular issue but would prevent some twoliners for sure. Finally, shouldn't we remove "Show after reboot" setting? (if bug 967475 comment 76 is the reason to have it)
Not sure who could answer the questions from comment 1
Flags: needinfo?(lebedel.delphine)
Hey Stef, I'll answer what I can. (In reply to Stefan Plewako [:stef] from comment #1) > Also in 2.0, as reported in http://bugs.aviary.pl/show_bug.cgi?id=4961 > In 3.0 this has been fixed (second line), maybe the fix could be backported? > 3.0 isn't open to l10n yet. So we can't compare with what 3.0 looks like right now from a localized perspective. Also given all the recent changes, we really don't know what 3.0 will look like yet, so maybe all this could change (ie margin, padding, etc) > Additional question, why we need so big margin here? I see that checkbox has > 15px "margin" on the left (flame) but on the right we set the gap to > 6.1rem=61px, > https://github.com/mozilla-b2g/gaia/blob/ > d50d05be5aaf02926d15b626ed8950d703df69d1/apps/settings/style/lists.css#L299 > Changing it to be the same on both side wouldn't fix this particular issue > but would prevent some twoliners for sure. Sorry, can't answer that. I think that's a UX decision, so might be worth reaching out directly to that team to get more insight on why they're doing it this way. That said, we're at the end of 2.2 cycle now, so I don't think we can expect this to change for 2.2 > > Finally, shouldn't we remove "Show after reboot" setting? (if bug 967475 > comment 76 is the reason to have it) I quickly looked at this bug and couldn't make much out of it. Seems like it's old and no decision was ever taken, so no outcome. Sorry can't help more on these questions, which should be more answered by devs I believe. One more thing: concerning margin/padding, there were some regressions from 2.1 to 2.2 and the way we are working this out is explained on https://groups.google.com/forum/#!topic/mozilla.dev.gaia/s3HyGQzk-Y4
Flags: needinfo?(lebedel.delphine)
(In reply to Delphine Lebédel [:delphine - use need info] from comment #3) > (In reply to Stefan Plewako [:stef] from comment #1) > > Also in 2.0, as reported in http://bugs.aviary.pl/show_bug.cgi?id=4961 > > In 3.0 this has been fixed (second line), maybe the fix could be backported? > > 3.0 isn't open to l10n yet. So we can't compare with what 3.0 looks like > right now from a localized perspective. Also given all the recent changes, > we really don't know what 3.0 will look like yet, so maybe all this could > change (ie margin, padding, etc) Such thinking makes me simply sad. How is 3.0 closed to localization? Is it just that 2.2 l10n wasn't separated from 3.0 (for some extremely strange reason) so you get 3.0 and 2.2 builds from the same l10n files? In case of pl/Polish these files correspond more to 3.0 then 2.2 but in all cases you could install nightly/3.0 l10n build and change language… and having done that, I can say that there is something in 3.0 now, that makes the difference and could be potentially backported. > Sorry, can't answer that. I think that's a UX decision, so might be worth > reaching out directly to that team to get more insight on why they're doing > it this way. I don't have good insight who should I ask and had hoped that you would be able to ni? right people.
(In reply to Stefan Plewako [:stef] from comment #4) > > Such thinking makes me simply sad. How is 3.0 closed to localization? Is it > just that 2.2 l10n wasn't separated from 3.0 (for some extremely strange > reason) so you get 3.0 and 2.2 builds from the same l10n files? In case of > pl/Polish these files correspond more to 3.0 then 2.2 but in all cases you > could install nightly/3.0 l10n build and change language… and having done > that, I can say that there is something in 3.0 now, that makes the > difference and could be potentially backported. It's not a question of "such thinking". It's a question that no one knows what 3.0 will look like, that it's still in the ideation process, and that there is therefore no use in opening it to l10n work because of this. There's no point in branching yet because we haven't finished testing on 2.2, and also because as I said, no one knows at this point what 3.0 will be. I don't think localizers would appreci > > > Sorry, can't answer that. I think that's a UX decision, so might be worth > > reaching out directly to that team to get more insight on why they're doing > > it this way. > > I don't have good insight who should I ask and had hoped that you would be > able to ni? right people.
(In reply to Stefan Plewako [:stef] from comment #4) > > Such thinking makes me simply sad. How is 3.0 closed to localization? Is it > just that 2.2 l10n wasn't separated from 3.0 (for some extremely strange > reason) so you get 3.0 and 2.2 builds from the same l10n files? In case of > pl/Polish these files correspond more to 3.0 then 2.2 but in all cases you > could install nightly/3.0 l10n build and change language… and having done > that, I can say that there is something in 3.0 now, that makes the > difference and could be potentially backported. It's not a question of "such thinking". It's a question that no one knows what 3.0 will look like at this point, because it's still in the ideation process - there is therefore no point in opening it to l10n work because of this. And there's also no reason to branch yet because we haven't finished testing on 2.2 and it would just confuse localizers at this point (having to tell everyone all of a sudden to work off another repo, etc.). Finally, because as I said, no one knows at this point what 3.0 will be. I don't think localizers would appreciate localizing a bunch of stuff that might just not show up there in the end. > > > Sorry, can't answer that. I think that's a UX decision, so might be worth > > reaching out directly to that team to get more insight on why they're doing > > it this way. > > I don't have good insight who should I ask and had hoped that you would be > able to ni? right people. Firefox UX is firefoxos-ux-bugzilla@mozilla.com, but i'm not sure this bug is the best area to ask them all this. Would probably try reaching out by email. For the rest of your questions, I don't know who you would have to reach out to for more info, sorry.
Delphine, you are right, 3.0 was not released or branched yet and no one knows how it will look like finally or with what version number it will ship. I should have been more specific when referring to 3.0-prerelease and probably name it trunk/nightly/development/master. Having said that, I doubt it would change much and your statements about some branch being closed for l10n, reasoning for it and other things and general insisting on 3.0 not being released are completely out of place. I regret I ni? you and won't do that again.
Assignee: nobody → splewako
WONTFIX (based on assumption that we shouldn't expect this to change for 2.2)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
(In reply to Stefan Plewako [:stef] from comment #7) > Delphine, you are right, 3.0 was not released or branched yet and no one > knows how it will look like finally or with what version number it will > ship. I should have been more specific when referring to 3.0-prerelease and > probably name it trunk/nightly/development/master. Long story short: what is currently on Gaia Master is not going to be exposed for localization until we understand what is going to happen with master. And right now nobody knows it. That's what Delphine meant by saying "3.0 is not open for localization". What seems like a simple fix (reduce the padding), will never be accepted at this point on 2.2. That's a CSS shared across the entire product, the number of potential regressions is huge. I had much smaller changes and with narrow scope refused earlier in the cycle. So yes, if you can't shorten that string the bug is in my opinion a WONTFIX.
Right on, thanks for explaining Flod. Stefan: feel free to ni' me again if needed. This wasn't meant to sound harsh - was just trying to explain all this
QA Whiteboard: [MGSEI-l10n-1F]
Whiteboard: LocRun2.2,MGSEI-l10n-1F → LocRun2.2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: