868317 - [Buri][Translation][German][Alarm]Alarm interface shows abnormally in German.

Status: RESOLVED DUPLICATE of bug 841761

(Firefox OS Graveyard :: Gaia::Clock, defect, P1)

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.085
 Firefox os  v1.0.1
 Mozilla build ID:20130422230201
 
 +++ This bug was initially created as a clone of Bug #448492 +++
 
 Created an attachment (id=401524)
 1
 
 DEFECT DESCRIPTION:
 Alarm interface shows abnormally in German.
 
  REPRODUCING PROCEDURES:
 1.Language is German;
 2.Launch clock ,add an alarm ,some words shows overlapping.->KO
 
  EXPECTED BEHAVIOUR:
 Shows normally.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 5/5
 
  For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #448492 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Clone from brother

Comment 2

[sync-1]

Attachment: 1

Clone from brother

Comment 3

[[e-mail], [e-mail]]

I think the issue could be fixed via Bug 832336 - [Clock] Clock settings need adjustment.

Comment 4

[田旻]

(In reply to Ian Liu [:ianliu] from comment #3)
> I think the issue could be fixed via Bug 832336 - [Clock] Clock settings
> need adjustment.

However, I have a different opinion with you. 

Bug832336 had a hot discuss on the display of several alarms, but it didn't give any specification of the display of different kinds of language at all.

Because different kinds of language have different style (like the length or numbers of words for the same meaning), some limitation should be add on the display of words on screen. I think this bug could also come out on any modules where  words are used to display on screen. We should pay more attention on it.

Comment 5

[[e-mail], [e-mail]]

I think that the root cause should be providing an enough space for the title/description of option. For the current design, title and description are placed in the same line. It means that they are sharing the width of screen. It will make the string truncated in many localization. 

Here are my suggestion:
* Don't place title and description in the same line(Bug 832336 should be a good solution.)
* Span line dynamically

Also ni. UX team to the discussion.

Comment 6

[田旻]

(In reply to Ian Liu [:ianliu] from comment #5)
> I think that the root cause should be providing an enough space for the
> title/description of option. For the current design, title and description
> are placed in the same line. It means that they are sharing the width of
> screen. It will make the string truncated in many localization. 
> 
> Here are my suggestion:
> * Don't place title and description in the same line(Bug 832336 should be a
> good solution.)
> * Span line dynamically
> 
> Also ni. UX team to the discussion.

What if one line isn't enough for the display? What if dynamically span is not good enough for the aesthetic reason?
I am looking forward to the new design of about these pr.

Comment 7

[Stephany Wilkes]

I believe we've (UX) have said "UI should adjust to fit text dynamically" in similar cases in the past. Assigning needinfo to Rob to see if we can clear this quickly, even though it's not leo, tef, or tracking (yet!).

Comment 8

[Rob MacDonald [:robmac]]

This layout definitely needs to be modified as a single word in this instance does not fit within the available space. Eric's work in bug 832336 addresses this by providing more space for labels. However, these labels should be limited to one line.

Comment 9

[田旻]

I think the use of other languages in other modules of system MAY also appear similar problems. It's a more universal problem since most display of words lack of a special scheme to deal with this over flow of words.

Comment 10

[Eric Pang [:epang] UX]

One line width provides much more space then sharing the space with the drop down select.  Is there a high chance that many languages will need more then one line for the label?  Can we specify that the translation should fit within one line?

Ideally we keep the labels to one line, but if you think this will be an issue I can create a mock up that covers any spill over to the second line (i'm just worried this will end up looking messy)

Also note, We've moved the previous alarm settings bug to bug 855426 (the mock up has been revised)

Comment 11

[田旻]

(In reply to Eric Pang [:epang] from comment #10)
> One line width provides much more space then sharing the space with the drop
> down select.  Is there a high chance that many languages will need more then
> one line for the label?  Can we specify that the translation should fit
> within one line?
> 
> Ideally we keep the labels to one line, but if you think this will be an
> issue I can create a mock up that covers any spill over to the second line
> (i'm just worried this will end up looking messy)
> 
> Also note, We've moved the previous alarm settings bug to bug 855426 (the
> mock up has been revised)
Yes, I agree with you. One line is enough. Two lines look messy. Maybe we should make a balance between UX adjustment and translation limitation.

Comment 12

[田旻]

Hi,everyone. Do you have any advance?

Comment 13

[Eric Pang [:epang] UX]

(In reply to 田旻 from comment #12)
> Hi,everyone. Do you have any advance?

I believe this will be taken care of in the following bug:https://bugzilla.mozilla.org/show_bug.cgi?id=855426

Mark as duplicate?

Comment 14

[田旻]

(In reply to Eric Pang [:epang] from comment #13)
> (In reply to 田旻 from comment #12)
> > Hi,everyone. Do you have any advance?
> 
> I believe this will be taken care of in the following
> bug:https://bugzilla.mozilla.org/show_bug.cgi?id=855426
> 
> Mark as duplicate?

I don't think it's ok because bug#855426 is a fixed bug. Few people will focus on it. What's more, this translation problem on UX is more detailed and special.

Comment 15

[Stephany Wilkes]

I'm sorry, but I am not clear on what work remains for UX here. Rob provided the UX recommendation above (one-line) and Eric reinforced that but also offered to do a mock-up showing spillover (in 855426). What is outstanding? Thanks!

Comment 16

[田旻]

In my opinion, cb message should not limited just in lock screen. What if user is using the mobile, then he will miss this cb message.

Comment 17

[田旻]

(In reply to 田旻 from comment #16)
> In my opinion, cb message should not limited just in lock screen. What if
> user is using the mobile, then he will miss this cb message.
Sorry, my last comment was written in a wrong place.

Comment 18

[田旻]

This problem still exists on newest build (ID:20130602070207).

Comment 19

[田旻]

Dose anyone have any advances about this problem?

Comment 20

[[e-mail], [e-mail]]

According comment 14, Bug 855426 is fixed in gaia master and v1-train. Not in v1.0.1. So, 田旻 still figures out the existed issue. ASAK, the feature of Bug 855426 is not in the scoop of v1.0.1. Needinfo UX team for the solution again. Thanks.

Comment 21

[Stephany Wilkes]

I am clearing the needinfo on FFOS-UX as both Rob (comment 8) and Eric (comment 10) addressed this and their feedback still seems to apply. If the issue has changed in nature, please let me know, but by all appearances this is an older issue resurfacing.