826221 - Header should display the same number of characters of an option's label

Status: RESOLVED FIXED

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

Description

[Francesco Lodolo [:flod]]

I'm testing desktop builds from here (tested with my language, Italian, and Spanish)
http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-b2g18/

I considered Portoguese for this example, but it's happening also for Italian in other menus.

Settings, there's a label called "Configurações de chamada". When you select this option you open a page with a title that reads "onfigurações de cham...".

Another example in Italian: "Archiviazione multimediale" becomes "Archiviazione multimedi..."

This shouldn't happen: if you display a string completely as a label, it should work also as a title (considering that's the same string).

Comment 1

[Marcia Knous [:marcia]]

Attachment: Screenshot of issue in Portuguese

Adding a screenshot so the triage team can see more clearly the issue flod is describing.

Comment 2

[Dietrich Ayala (:dietrich)]

Not blocking because it's a l10n change, not a Gaia code change.

+Stas

Comment 3

[Francesco Lodolo [:flod]]

(In reply to Dietrich Ayala (:dietrich) from comment #2)
> Not blocking because it's a l10n change, not a Gaia code change.

Unless I don't understand how this works, it looks the opposite to me: it's Gaia that should display correctly the same string in both situations, isn't it?

Comment 4

[Axel Hecht [:Pike]]

Re-requesting basecamp.

Unless we can find a solution within the language, we'll need to find a solution in the code.

Removing the late-l10n keyword, though, as I don't expect the answer to be requiring l10n follow-up at this point. It's more about allowing more space, thus adding l12y, aka localizabilty.

Comment 5

[Francesco Lodolo [:flod]]

Wow, this is an interesting approach. Care to explain?

Comment 6

[Casey Yee]

The ellipsis of the text in the header is the correct behavior and to spec.   The solution here is to shorten the header text to fit the available area.   We do shrink header text to fit in any other areas where we experience the same issue.

Comment 7

[Casey Yee]

Correction to above comment:  We do _not_ shrink header text to fit text into header in any areas of the UX in FFxOS.

Comment 8

[Francesco Lodolo [:flod]]

Are you really interested in having Gaia localized in something other than English? 
Because I can't see it happen if this is the "spec". There's a limit to the amount of abbreviations you can put into a string and still make some sense.

Comment 9

[Staś Małolepszy :stas]

Attachment: Let's not do this, ever

Wontfixing a bug without any comment isn't particularly helpful to the discussion.  Please don't do that.  I know the context -- it's a workweek time, the home stretch, a sprint towards the final milestone, many bugs and even more bugmail.  But please be considerate of other people who took time to file this bug in hope to make Firefox OS better.

The reality of localizing software is that of being able to find compromises, especially when it comes to sizing.  We want to be sensitive to sizing issues, but -- in particular on mobile devices -- the space is limited.  I trust that everyone on this bug knows this, so forgive me for stating the obvious.

When space is limited, we have a few solutions to choose from:

 - code solutions:

   (a) reduce font size,
   (b) truncate and add … at the end,
   (c) truncate and add … in the middle,
   (d) truncate and add a fade effect mask (cf. bug 805977 and attachment 692890 [details]).
   (e) animate a horizontal scrolling animation, a marquee-of-sorts.

 - localization solutions:

   (f) find a shorter translation (hard, and sub-optimal),
   (g) drop part of the translation, e.g. "call settings" becomes "calling" (you're in the Settings apps after all),
   (h) abbreviate.

The localizer in me thinks 'god, no' when I think of using abbreviations (h).  See the attached picture.  I took it a few months ago when my dad asked me what the text in Polish meant.  I had no idea and it took me a while to figure it out.  It's so absurd it's almost funny.  It would be equally ridiculous to abbreviate "Drag item to rearrange.." in English to "Dr. it. to rea."  So yeah, let's not do this.

At the same time, I understand that varying the font size in the UI (a) is a no-no for interaction and visual designers.  That's the spec Casey is talking about.

So we're left with (b) through (g), and this is where we add the release schedule to the mix :)  With January 15 looming around the corner, I think it's safe to drop more complex solutions for now, like (c) or (e).

The current code solution is (b).  We have an implementation for (d) - the fade effect - from bug 805977.   Casey, what do you think about it?

On the localization side, we could try the (g) approach, but it won't work for all strings.

Comment 10

[Staś Małolepszy :stas]

(In reply to Staś Małolepszy :stas from comment #9)

> We have an implementation for (d) - the fade effect - from bug 805977.

Casey, what do you think about it?

Comment 11

[Francesco Lodolo [:flod]]

Truncate is far from being a solution, a safe word could easily become a swear word.

Having said that, I'm aware that space is a problem on mobile devices, what I expect is: if you're reusing a string (correct me if I'm wrong, I did check only quickly), it should be displayed in the same way in all contexts where it's used.

Comment 12

[Casey Yee]

Please accept my apologies.  I certainly didn't mean to close off conversation.   My bad.

> We have an implementation for (d) - the fade effect - from bug 805977.
> Casey, what do you think about it?

I'm not sure this buys us a whole lot more room.   I think maybe 1 or 2 characters at best in the header example that is attached to the bug.  I don't suspect that this is sufficient for many cases but may be enough to get us by for V1.  

I think it will be useful to run through some examples where this is an issue and discuss some of the options that are presented.   I suspect there are some cases where we can rejig layout to work around the issue.

Francesco.  Are you here at the work week?   Can we find some time to chat about this?

Comment 13

[Casey Yee]

I also had a chat with Kaze about this issue and it sounds like he is working on a list of strings that are experiencing this issue.   Depending on the magnitude of the problem we can determine whether or not solution D is sufficient or if we will need to consider the more complex solutions.

Comment 14

[Francesco Lodolo [:flod]]

(In reply to Casey Yee [:cyee] from comment #12)
> Francesco.  Are you here at the work week?   Can we find some time to chat
> about this?

Nope, just a volunteer from Italy ;-)

Can someone check how many characters are displayed when a string is used as a label and how many when used as a header? At least we can understand how big the difference is.

I realize that this comes very late in the development, but I personally started testing desktop builds only a couple weeks ago. In the long period we should also start thinking about wrapping long labels instead of truncating them (e.g. check the Settings page in Spanish, at least in the desktop builds).

Comment 15

[Axel Hecht [:Pike]]

Casey, I could reproduce this with two of the existing settings strings in pt-BR, "Configuracoes de cham..." and "Permissoes de aplicativ..."

Comment 16

[Staś Małolepszy :stas]

For Spanish:

Configuración de llamadas
Seguridad de la tarjeta SIM
Permisos de la aplicatión

And the following three are truncated even as labels in the list of Settings:

Informacion del dispositi…
Dispositivo de almacena…
Almacenamiento miltim…

Comment 18

[Francesco Lodolo [:flod]]

I think we can consider this fixed by other bugs.
1) we generally use different strings for labels and headers (e.g. bug 944749)
2) header's font resizes on 2.0+ to display longer strings (bug 908300)