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

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: mdaniloff, Assigned: erkan)

Tracking

({l12y})

unspecified
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:-)

Details

(Whiteboard: [leo-triage])

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
Created attachment 776788 [details]
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

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

Updated

5 years ago
Flags: needinfo?(firefoxos-ux-bugzilla)
blocking-b2g: --- → leo?
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
Can we please help with assigning a warm body here?
Flags: needinfo?(bugmail)
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.
Flags: needinfo?(rmacdonald)
Flags: needinfo?(pabratowski)
Flags: needinfo?(bugmail)
Triage - not blocking, leave decision to moz triage.
Whiteboard: [leo-triage]
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.
Flags: needinfo?(pabratowski)

Comment 7

5 years ago
The word is "Kimden".
That's not too big. Can we try to reduce the padding to see if that makes a difference?

Updated

5 years ago
blocking-b2g: leo? → leo+
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?
Flags: needinfo?(selim)
Flags: needinfo?(rmacdonald)
Flags: needinfo?(firefoxos-ux-bugzilla)

Comment 10

5 years ago
(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.
Flags: needinfo?(selim) → needinfo?(dwayne)
moving to leo? as from in Turkish (although shortened) is readable and can make sense of it.
blocking-b2g: leo+ → leo?
work around available and hence minus
blocking-b2g: leo? → -

Comment 13

5 years ago
(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?
Flags: needinfo?(bugmail)
Created attachment 803718 [details] [diff] [review]
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).
Attachment #803718 - Flags: review?(selim)
Flags: needinfo?(bugmail)

Updated

5 years ago
Attachment #803718 - Flags: review?(selim) → review+

Comment 15

5 years ago
Thank you, Andrew.

Just pushed it: https://hg.mozilla.org/gaia-l10n/tr/rev/64d6255ab3cb
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Flags: needinfo?(dwayne)
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 8391227 [details]
Screenshot on current master
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.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → WORKSFORME
(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.
(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.
You need to log in before you can comment on or make changes to this bug.