Please provide a consistent, app-wide format for displaying the "Type ? Carrier ? Number" strings. Once provided, all strings will be updated and tests modified to prove conformance. Requesting leo? because there are too many ad hoc changes made across different bugs and no single point where the change has been declared, resulting in inconsistency across the app.

Hi Rick Actually we do have a consistent format / algorithm for the presentation of 'Type / Carrier / Number' strings. It has been in place long before V1.0. Unfortunately the problem is the on-boarding process into this project has not been optimal for the propagation of knowledge. The information you seek is as follows: If for a single contact we have: 1) …a unique string in the <carrier> field and a unique string in the <type> field output: <type>, <carrier> 2) …no content in the <carrier> field output: <type>, <phone number> 3) …two phone numbers that have exactly the same content in the <type> field and in the <carrier> field output: <type>, <phone number> 4) …no content in the <type> field output: <phone number> In terms of Visual Treatment the wireframes are just representational. The Visual Design is the specification for Visual Treatment. So for example in the wireframes you will see the separator is a bar '|' but in visual design it is a comer ','. in this situation Visual Design is King. Just referring to your attachments. attachment 763619 [details] and attachment 763623 [details] For these two follow the Visual Design guidelines and use the appropriate building block. If an appropriate building block is not available contact Victoria to seek her guidance. attachment 763617 [details] annotation 03 details a phone number that belongs to a 'Contact that is in the group message but not in the users contact list'. It is therefore not covered by points 1 to 4 above If you need any more guidance or clarification NeedInfo me anytime.

Does this truly block the leo+ bug 880624? There was some back and forth in that bug.

Alex, my hope had been that the spec would be updated with a final word.

Triage- removing leo? as this doesnt really block anything at the moment.

Victoria, should this block the 1.1 release ?

Hi Julien, This is not blocking from a Visual Design point of view. This decision of changing "|" to "," was taken due to a localization bug you reported or you commented in. From an UX perspective, this is an important issue to solve due to consistency matters. We need to provide a consistant way of displaying this kind of information so it's not misunderstood by the user.

I think it was initially because of consistency between all apps, not only in Sms, and this information was shown like this in other apps.

Triage confirms blocking-.

(In reply to Julien Wajsberg [:julienw] from comment #12) > I think it was initially because of consistency between all apps, not only > in Sms, and this information was shown like this in other apps. Confirm; for example, the Dialer app displays something like "mobile | 9995551234"

Victoria, coming back here, do you think we can take the visual refresh as an opportunity to try and get some consistency here? Thanks !

(In reply to Julien Wajsberg [:julienw] from comment #15) > Victoria, > > coming back here, do you think we can take the visual refresh as an > opportunity to try and get some consistency here? > > Thanks ! I wouldn't mind, but just affraid that if we do block refresh with fixes that are not really part of the refresh it will put the refresh in danger. But for consistency we should fix this issue. I have been told a while ago that the use of "|" was discarded for localization issues, so we moved towards the comma ",". I would go for the comma.

So that means we should use the comma for all cases, right? Note that in Bug 931119 we're making the separator localizable (in the messages app at least, but this could be done elsewhere), so I don't think the localization issues should be taken into account as all separators will be able to be changed.

OK, great for other cases, but unless we feel the separator is better, I would go for the comma. Let's go for the comma then.

Was resolved in the scope of bug 925404. Master: https://github.com/mozilla-b2g/gaia/commit/3aaf653afdbcc41daf565886ce4d3228264259f2 Demo can be seen here: https://wiki.mozilla.org/Gaia/SMS/Scrum/3#bug_925404:_Always_include_the_phone_number_in_the_SMS_Thread_UI.2C_even_if_the_carrier_is_known Description os this bug is different from bug 925404, so don't mark it as DUPLICATE.