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)
Tracking
(b2g-v2.1 affected, b2g-v2.2 affected)
VERIFIED
WONTFIX
People
(Reporter: yue.xia, Assigned: stef)
References
Details
(Whiteboard: LocRun2.2)
Attachments
(2 files)
[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
Assignee | ||
Comment 1•10 years ago
|
||
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)
Assignee | ||
Comment 2•10 years ago
|
||
Not sure who could answer the questions from comment 1
Flags: needinfo?(lebedel.delphine)
Comment 3•10 years ago
|
||
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)
Assignee | ||
Comment 4•10 years ago
|
||
(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.
Comment 5•10 years ago
|
||
(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.
Comment 6•10 years ago
|
||
(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.
Assignee | ||
Comment 7•10 years ago
|
||
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
Assignee | ||
Comment 8•10 years ago
|
||
WONTFIX (based on assumption that we shouldn't expect this to change for 2.2)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Comment 9•10 years ago
|
||
(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.
Comment 10•10 years ago
|
||
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
Updated•9 years ago
|
QA Whiteboard: [MGSEI-l10n-1F]
Whiteboard: LocRun2.2,MGSEI-l10n-1F → LocRun2.2
Reporter | ||
Updated•9 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•