967863 - [B2G][L10n][Contacts] When adding a “New Contact” The Mobile and Personal words are truncated

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::Contacts, defect)

Description

[Salem Elkabule]

Attachment: In Contact Mobie and Home truncation italian.png

Description:
When user attempts to add contact within Contact App, The “Mobile" field and the “Home” field are truncated in Italian

Repro Steps:
1) Updated Buri Build ID: 20140203004001
2) Have the device language set to “Italian”  
3) Restart the device
4) Open the "Contacts" app 
5) Select (+) to add a new contact

Actual Result: 
The Word “Mobile” and “Home” are truncated Italian

Expected:
The Words “Mobile” and “Home” do not appear truncated 

Environmental Variables
Device: Buri V1.3 MOZ RIL
Build ID: 20140203004001
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/3d9d920ca43b
Gaia: f9a37c77efb4621a1f57e4695b497d18601fe134
Platform Version: 28.0a2
Firmware Version: V1.2-device.cfg


Repro frequency: 100%
See attached: Screenshot

Comment 1

[Salem Elkabule]

This issue reproduces on 1.2

1.2
Environmental Variables
Device: Buri V1.2 MOZ Ril
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/9250d1b1cb6e
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Platform Version: 26.0
Firmware Version: V1.2-device.cfg

The Word “Mobile” and “Home” are truncated Italian

Comment 2

[Francesco Lodolo [:flod]]

Some notes: truncated labels are "MOBILE" and "PERSONAL" (not HOME, which is "CASA" in Italian).

This is a long standing UI problem in Contacts, and English has definitely the same problem: "PERSONAL" becomes "PERSONALE" in Italian (one more char), and it's displayed as "PERSO…".

Delphine, do we already have a bug for this with UX?

Comment 3

[Delphine Lebédel [:delphine - OOO]]

Maybe Bug 927785 ? Not sure if related, asking UX input

Comment 4

[Stephany Wilkes]

I have some questions on this one. First, I'm flagging Jason to see if he knows the status of bug #927785. If it's marked koi+, it should have landed in 1.2, but the comment over in bug #927785 implies that it has not/will not for some reason. And if it missed 1.2, should it not be in 1.3? I can't find any reasons, in the thread over there, that might explain why it wasn't picked up and marked Fixed.

From what I can see (which may be wrong), it does look like bug #927785 would fix this, but I'm flagging Eric to confirm.

Comment 5

[Jason Smith [:jsmith]]

That patch apparently never landed on 1.3 or later.

Kaze - Do you know why? Looks like we need this landed on 1.3 or later here.

Noming as this is then a regression from a koi+ blocker, as the patch never landed on 1.3.

Comment 6

[Francesco Lodolo [:flod]]

Note: see also old bug 830717.

Comment 7

[Fabien Cazenave [:kaze]]

This is not a regression — at least not a recent one, since I can see this bug with the 1.1 branch too.

This is a pure UX issue, and it’s specific to the “New Contact” and “Edit Contact” panels. I think we’ve had this truncation for a very long time — it probably started when it’s been decided to capitalize these labels (“mobile”, “personal”…). Using lowercase labels would be better for English but we’d probably still have issues with other locales.

I think these panels need a UI refresh — pinging UX to get a new spec, and taking this bug for the implementation part.

My two cents: as the horizontal screen estate is very limited, I would suggest to put these labels (Mobile, Personal, Home, Work, etc.) on a line above the text fields rather than in a column. That would be closer to the UI in display mode, it would allow our l10n contributors to provide better translations, and it would leave more room for some text fields like mail address and address (which don’t fit either).

Side note: rather than using “Label” sub-panels, these modifiable labels would be a perfect use case for <datalist> but I’m not sure it’s supported yet by FxOS…
  <input type="text" name="label" list="contactType"/>
  <datalist id="contactType">
    <option>Mobile</option>
    <option>Personal</option>
    <option>Home</option>
    <option>Work</option>
  </datalist>

(In reply to delphine from comment #3)
> Maybe Bug 927785 ? Not sure if related, asking UX input

Unrelated.
Bug 927785 was causing a lot of truncation issues because we had too much padding in some text boxes, but this case is a different story. There are lots of different causes for these string truncations; bug 927785 didn’t claim to solve them all.

(In reply to Jason Smith [:jsmith] from comment #5)
> That patch apparently never landed on 1.3 or later.
> 
> Kaze - Do you know why? Looks like we need this landed on 1.3 or later here.
> 
> Noming as this is then a regression from a koi+ blocker, as the patch never
> landed on 1.3.

For bug 927785 I wrote a 1.2-specific patch on your demand, see bug 927785 comment 27.
For the master and 1.3 branches, this padding issue has been fixed with bug 917704 & bug 929565.
Again, this has no impact on this bug anyway.

Comment 8

[Jason Smith [:jsmith]]

Okay - thanks for the clarification. Clearing the nom here then.

Comment 9

[Stephany Wilkes]

Thank you so much, Kaze. Your comment is really helpful. I am flagging Casey and Harly (Harly is lead on Building Blocks) to see about slotting this as part of our OS-wide standardization and improvement backlog. We discussed a few ideas around this during our work week last week (after a great L10N presentation) and this would be a good item to add to our list, I think.

Comment 10

[Fabien Cazenave [:kaze]]

My pleasure. :-)

FWIW I don’t think this is directly related to the Building Blocks. The capitalization is (was?) part of an OS-wide rule, but the two-column layout of these panels is very specific to the Contacts app — I can’t think of any other app using this layout.

Comment 11

[Harly Hsu[:harly]]

Having seen the new contact visual refresh proposal, I think that this could be dealt by making the Mobile selector a separate row, but for Building Blocks, we still need to define what we should do if selector exceeds limit.

Comment 14

[Rimas Kudelis [use needinfo to ping]]

Is there any way to see this fixed (even if not perfectly) before 1.4 is released? What :kaze proposed in Comment #7 (moving the type selector to a separate row above) seems like an obvious solution. Why is it so long to materialize?

Comment 18

[Francesco Lodolo [:flod]]

I guess at this point we should just close this: it's fixed on master, and I don't see the new design (or a fix) landing on 1.4 at this point.

Comment 19

[Delphine Lebédel [:delphine - OOO]]

Agreed.
Closing as per comment 18