1047625 - [B2G][2.0][l10n][Calendar] Dutch: "Add event" header string displays truncated

Status: RESOLVED WONTFIX

(Mozilla Localizations :: nl / Dutch, defect)

Description

[Adam Alldredge [:AdamA][Inactive]]

Attachment: Header truncated

Description:
When users are in Dutch language, upon adding a new event to the users calender, the "Add event" string for the header displays truncated 

Repro Steps:
1) Update a Flame to 20140801000201
2) Change language to Dutch(Nederlands) and restart the phone
3) Select Calendar> Click the "+" in the top right corner
4) Observe "Add Event" header

Actual:
"Add event" header is truncated when adding an event to users calendar

Expected:
String displays correctly without truncation.

Environmental Variables:
Device: Flame 2.0
Build ID: 20140801000201
Gaia: 1d1a47a1135d8ce44db9b88db4d2ea6f454cf0a8
Gecko: e57d9f525233
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Notes:
This string has been modified from 1.4, it is not truncated in that build.

Repro frequency: 3/3
Link to failed test case: https://moztrap.mozilla.org/manage/case/13903/
See attached: Screenshot

Comment 1

[KTucker [:KTucker][Inactive 3/4/2016]]

Please comment your branch check in a separate comment with the environmental variables.

Comment 2

[Adam Alldredge [:AdamA][Inactive]]

This issue does not occur on 1.4 Flame.

Environmental Variables:
Device: Flame 1.4 (319mb)
Build ID: 20140801000200
Gaia: 3feb37ee2ed2319c9e556728723a5517dc1663ea
Gecko: 2b5defe2d811
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Actual result:
This string is different in 1.4 and is not truncated.

Comment 3

[Ton [:Tonnes]]

This string hasn’t changed between 1.4 and 2.0, neither in en-US nor nl. Instead and most likely, the seoond word (toevoegen) isn’t visible at all in 1.4, hence the truncation becomes visible in 2.0 and 2.1 pre.

There is no solution to shorten text for nl. Either:

1) the header field should have enough room by design (not just 0.6 x screen width or just as much as en-US strings)
2) the font should get smaller automatically, or
3) the text should wrap to 2 lines.

Note that this problem also exists for Edit event.

Comment 4

[Francesco Lodolo [:flod]]

Two thoughts (the complete string is "Gebeurtenis toevoegen", right?).

1) I wonder why the header font doesn't resize. The header space in 2.0 is smaller than 1.4 because the back button is larger, but we also have systems to resize the font. Not sure if the text is too long, or the system just fails.

2) As a workaround, "Add event" and "Edit events" have separate labels for header and button. In the header you could keep only "Add" and "Edit" since it's clear you're in the event context.

Comment 5

[Ton [:Tonnes]]

(In reply to Francesco Lodolo [:flod] from comment #4)
> Two thoughts (the complete string is "Gebeurtenis toevoegen", right?).

Yes.

> 1) I wonder why the header font doesn't resize. The header space in 2.0 is
> smaller than 1.4 because the back button is larger, but we also have systems
> to resize the font. Not sure if the text is too long, or the system just
> fails.

I wasn’t sure about this, but now you mention it, I agree.

> 2) As a workaround, "Add event" and "Edit events" have separate labels for
> header and button. In the header you could keep only "Add" and "Edit" since
> it's clear you're in the event context.

That’s a known workaround, and most people don’t like them. I’d prefer a permanent solution where space is never an issue, strings can be translated without giving in to their meaning, developers being aware of the fact they’re developing for tens of locales instead of English only and localizers not needing to keep track of all workarounds in order to fix the original strings afterwards whenever (and if) a real solution is there.

Comment 6

[Francesco Lodolo [:flod]]

(In reply to Ton from comment #5)
> I’d prefer a permanent solution where space is never an issue

I doubt we'll ever have that, especially on mobile. 

Given the current non ideal situation (space is too small), is obviously up to you to make a decision: a) ship the best translation possible, knowing that the user will never see it b) accept compromises (if there any, sometimes there aren't). Personally I choose the second.

Comment 7

[Ton [:Tonnes]]

(In reply to Francesco Lodolo [:flod] from comment #6)
> (In reply to Ton from comment #5)
> > I’d prefer a permanent solution where space is never an issue
> 
> I doubt we'll ever have that, especially on mobile. 

I seriously can’t think of a single reason why not. Can you?

> Given the current non ideal situation ... Personally I choose the second.

I agree if it’s a temporary issue, but I doubt it is. If needed, I’ll elaborate outside Bugzilla.

Comment 8

[Francesco Lodolo [:flod]]

(In reply to Ton from comment #7)
> I seriously can’t think of a single reason why not. Can you?

Because I don't know any mobile OS where space for UI is not an issue. Screen size is limited, even if resolution increases the amount of elements you can display is limited as well.

Comment 9

[Ton [:Tonnes]]

This may be true in general, but I don’t think these OS’es set English string widths as default (withouh notifying localizers) and appear to take a little more care about available UI space by making another line available, if you ask me.

Note that I’m talking basic errors like using text between two buttons (in headers mostly) and not wrapping to two lines where this can be an easy solution, or not taking larger widths into account if an English string contains a few i’s and barely fits, where the same amount of characters with less i’s already cause problems for other locales.

It’s like many English strings in the UI are considered to determine the width and the UI is adapted to that, while instead, I’d take 1.3 x English string width and set the available space accordingly, just like in a regular OS. This would elminate more than half the so-called l10n bugs.

Comment 10

[BMO Automation]

We've stopped shipping Firefox OS for phones. Thus resolving this as WONTFIX.