894696 - [B2G][l10n][Email]Turkish: The "From" tab in the search email screen is truncated in Turkish

Status: RESOLVED WORKSFORME

(Mozilla Localizations :: tr / Turkish, defect)

Description

[mdaniloff]

Attachment: turkishfromtabtrunc

The "From" tab in the search function of the Email app is truncated when the device is set to display the Turkish language.

Repro Steps:
1) Update Leo to Build ID: 20130716070204
2) Change the device language to Turkish (Turkce) and reboot if necessary.
3) Launch the E-pošta app then login with a valid account.
4) Once the emails have finished loading, tap the magnifying glass icon in the lower right corner of the screen.

Actual:
The "From" (Kimd...) tab text is truncated.

Expected:
All text is displayed in full

Environmental Variables
Build ID: 20130716070204
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/629020cf576b
Gaia: fb9362d34260771d4a00b9a0e10a6bbad397bd3b
Platform Version: 18.1

Notes:
Repro frequency: 100%
See Attached screenshot

Comment 1

[Selim Şumlu]

In Turkish, there is no way to shorten this word any more. We definately need a fix on the interface side.

Comment 2

[Delphine Lebédel [:delphine - Use needinfo]]

No workaround was found by localizer (ie taking into account UX l10n recommendations https://docs.google.com/document/d/16P56U6bSM1KVunkCG3WLmtH1cmhQf7YxT4mTPyWAnUw/edit )
Therefore marked as blocker for Leo and asking UX help

Comment 3

[Preeti Raghunath(:Preeti)]

Can we please help with assigning a warm body here?

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

This is largely a UX or Visual Design call.  The options I can think of involve some combination of the below:
- Make the font smaller.
- Reduce the padding
- Make the text flow across two lines

The good news is that the localization engine is secretly much more powerful than you would expect.  You can set any arbitrary attribute value on a localized node tagged with a data-l10n-id that you want.  For example, the "style" attribute that lets you put CSS styling on.  While this should only be used as a last resort, this seems like a last resort type of thing.

Here's the CSS we're dealing with from https://github.com/mozilla-b2g/gaia/blob/v1-train/shared/style_unstable/tabs.css#L156
[role="tablist"][data-type="filter"] > [role="tab"] > a {
  display: block;
  padding: 0 0.5rem;
  text-decoration: none;
  color: #737272;
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
  background-color: transparent;
  font: normal 1.6rem/4rem "MozTT", Sans-serif;
  width: auto;
  float: none;
}

The key bit for us is the font line that nets us the equivalent of "font-size: 1.6rem;" and probably the padding directive which is putting padding on both sides.

As such, I suggest adding a property like so to the properties file for this locale and any other affected locales:

message-search-from.style=font-size: 1.4rem; padding: 0;

This works for me with "message-search-from=Kimden" in a DEBUG=1 profile run in Firefox nightly.  It might need a little more tweaking on a real device.


I'm needinfo-ing Rob, the current UX lead for the e-mail app, and Przemek, the VD lead for the e-mail app (to the best of my knowledge.)  Please ping them directly if they don't comment here in a timely fashion.

Comment 5

[Wayne Chang [:wchang]]

Triage - not blocking, leave decision to moz triage.

Comment 6

[Przemek Abratowski [:przemek] UX]

Does anyone know how long the word for "from" in Turkish is? I tried to check online but I'm getting a different word for "from" (itibaren).

If the word is a letter or 2 larger then we should reduce the padding to make it fit, if that doesn't work then we should reduce the font size by one point in the tab for Turkish only. This change should not effect the English tab font size.

Comment 7

[Selim Şumlu]

The word is "Kimden".

Comment 8

[Przemek Abratowski [:przemek] UX]

That's not too big. Can we try to reduce the padding to see if that makes a difference?

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

I'm clearing the UX needinfo's since we have an answer from Visual Design.

Selim, do you need any assistance fixing this?  I see from https://hg.mozilla.org/gaia-l10n/tr/log that Pootle is in use, so me directly pushing fixes to the repo at https://hg.mozilla.org/gaia-l10n/tr/ does not seem correct.  It looks like Pootle doesn't want to make it easy to arbitrarily add new strings, but perhaps using 'download' and then 'upload' from http://mozilla.locamotion.org/tr/firefoxos/apps/email/email.properties.po would work?

Comment 10

[Selim Şumlu]

(In reply to Andrew Sutherland (:asuth) from comment #9)
> It looks like Pootle doesn't want to make it easy to
> arbitrarily add new strings, but perhaps using 'download' and then 'upload'
> from
> http://mozilla.locamotion.org/tr/firefoxos/apps/email/email.properties.po
> would work?

I don't think that would be a permanent solution. Let's see what Dwayne would suggest.

Comment 11

[Preeti Raghunath(:Preeti)]

moving to leo? as from in Turkish (although shortened) is readable and can make sense of it.

Comment 12

[Preeti Raghunath(:Preeti)]

work around available and hence minus

Comment 13

[Selim Şumlu]

(In reply to Andrew Sutherland (:asuth) from comment #9)
> I'm clearing the UX needinfo's since we have an answer from Visual Design.
> 
> Selim, do you need any assistance fixing this?  I see from
> https://hg.mozilla.org/gaia-l10n/tr/log that Pootle is in use, so me
> directly pushing fixes to the repo at https://hg.mozilla.org/gaia-l10n/tr/
> does not seem correct.  It looks like Pootle doesn't want to make it easy to
> arbitrarily add new strings, but perhaps using 'download' and then 'upload'
> from
> http://mozilla.locamotion.org/tr/firefoxos/apps/email/email.properties.po
> would work?

As we haven't heard from Dwayne yet, I think it's time to patch this manually for this version. Andrew, can you help with this?

Comment 14

[Andrew Sutherland [:asuth] (he/him)]

Attachment: turkish fix

Here's a patch that does what I proposed.  It's possible this should be reflected into pootle.  I tried to push this to the repo under the assumption that it's better than nothing even if the next pootle update backs it out, but I lack push privileges to the repo (makes sense).

Comment 15

[Selim Şumlu]

Thank you, Andrew.

Just pushed it: https://hg.mozilla.org/gaia-l10n/tr/rev/64d6255ab3cb

Comment 16

[Andrew Sutherland [:asuth] (he/him)]

Hm, it appears this was reverted by the automated push from pootle a few days later at:
https://hg.mozilla.org/gaia-l10n/tr/rev/6c4396b8dcca

I have no idea how to make pootle not break this.

Comment 17

[Francesco Lodolo [:flod]]

Attachment: Screenshot on current master

Comment 18

[Francesco Lodolo [:flod]]

Application is showing the entire word without the added string on current master, marking as WORKSFORME (maybe FIXED works too, but issue wasn't actually fixed in this bug).

In general, I don't think that adding inline CSS styles inside localization files is a winning strategy. As you noticed, it breaks several tools (no string to translate => string will be removed, if not string will be reported as obsolete by other tools), and definitely makes QA more difficult.

Comment 19

[Francesco Lodolo [:flod]]

(In reply to Francesco Lodolo [:flod] from comment #18)
> In general, I don't think that adding inline CSS styles inside localization
> files is a winning strategy. As you noticed, it breaks several tools (no
> string to translate => string will be removed, if not string will be
> reported as obsolete by other tools), and definitely makes QA more difficult.

Adding maintainability as another negative: let's say 1.6 you decide to redesign the app, but keep the existing string because, well, a subject is always a subject. And the inline style will remain as well, even if it's not relevant anymore.

Comment 20

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Francesco Lodolo [:flod] from comment #19)
> (In reply to Francesco Lodolo [:flod] from comment #18)
> > In general, I don't think that adding inline CSS styles inside localization
> > files is a winning strategy. As you noticed, it breaks several tools (no
> > string to translate => string will be removed, if not string will be
> > reported as obsolete by other tools), and definitely makes QA more difficult.
> 
> Adding maintainability as another negative: let's say 1.6 you decide to
> redesign the app, but keep the existing string because, well, a subject is
> always a subject. And the inline style will remain as well, even if it's not
> relevant anymore.

Agreed that it's a bad strategy in general.  For email at least I try to adhere to the rule that we generate new string id's whenever the context of the string changes, which includes non-trivial changes in screen real estate.  Visual design changing things by a few pixels probably would not get a new string, however.