[l10n] UX team, remember that Gaia NEEDS to be localized

[Guillermo López Leal]

Hi all,

This is a friendly reminder of a translator that is tired of shortening
strings in our translations that are perfectly understandable in
English, but that are impossible to understand in our language.

Keep in mind that space is really small, and I am sure that you have
tried to shorten the English strings to fit in that space, but usually
Latin languages (Spanish, French, Italian...) take more space to say the
same without loosing any meaning.

Please, be aware that you must (not "should", but "must") remember that
Gaia is not just for English speakers, but for all the world. And you
need to take care of the space for different languages. We have been
doing this for a decade thanks to Pike and others on the l10n team for
desktop, and we would like to continue this relationship with FirefoxOS.

Sincerely,

a trillion bugs on [es] component without a good solution.

PS: also, if you are a gaia developer whose mother tongue is not
English, please remember that your strings might be translated to your
language. Try it. If they do not fit: tell UX.

[Andrew Sutherland]

On 11/29/2013 09:19 AM, Guillermo López Leal wrote:
> Keep in mind that space is really small, and I am sure that you have
> tried to shorten the English strings to fit in that space, but usually
> Latin languages (Spanish, French, Italian...) take more space to say the
> same without loosing any meaning.

A potential work-around for apps is that specific localizations can
apply CSS overrides for elements localized on the basis of their
data-l10n-id. However, it won't work in cases where code manually uses
mozL10n.get() and then uses textContent/etc. to set the string. So if
the string changes on the fly when you change the device locale, the
trick probably works. All existing localizations that manually set
textContent should instead migrate to using mozL10n.localizeElement so
the trick and on-the-fly locale switching works transparently.

Specifically, if your data-l10n-id is "foo", you can do things like:

foo=A Long String
# Clobber the explicit style on the
# Supported since v1.0.1
foo.style=font-size: 1.4rem; padding: 0;
# Supported on v1.1 since the uplift of bug 884489 on July 2nd.
foo.style.padding=0

There is also explicit support for nested property setting on 'dataset'
in addition to style. Other DOM properties can also be set, but only a
single level of properties is supported unless white-listed.

Important note! Because this is being set via the CSSOM, the Content
Security Policy (CSP) for certified apps which forbids 'unsafe-inline'
styles does not apply! (This is explicitly codified in
http://www.w3.org/TR/CSP/#style-src.) But if you were to try and test
things by putting an equivalent 'style' attribute in the HTML source, or
maybe even using the DOM inspector, those won't work! (Unless the DOM
inspector does something clever or the setAttribute call propagates the
chrome privilege, etc.)

For more info on the capabilities of the l10n code, see the unit tests
confusingly located in the gallery component:
https://github.com/mozilla-b2g/gaia/blob/master/apps/gallery/test/unit/l10n_test.js

https://bugzilla.mozilla.org/show_bug.cgi?id=841422 is the bug on making
the unit tests be in a less confusing location.

Other context: bug https://bugzilla.mozilla.org/show_bug.cgi?id=892075
is a meta bug for the many, many, many cases of problems related to
truncation/overlaps.

Andrew

[Axel Hecht]

On 12/1/13 9:49 PM, Andrew Sutherland wrote:

Sorry, but this horrible. The UX is stuff that should happen on the side
of UX, and not on the side of localizers trying to work around design
problems.

We can't assume that localizers will manage the code creation you
suggest here, and the QA complexity this introduces is terrifying.

Axel

[Dale Harvey]

Seems like it would be possible for us to write a tool that ran integration
tests in various locales and reported us hitting string overflows? not
quite sure how it would be possible to detect them, but seems possible

On 1 December 2013 23:07, Axel Hecht <l1...@mozilla.com> wrote:

> On 12/1/13 9:49 PM, Andrew Sutherland wrote:
>

> Sorry, but this horrible. The UX is stuff that should happen on the side
> of UX, and not on the side of localizers trying to work around design
> problems.
>
> We can't assume that localizers will manage the code creation you suggest
> here, and the QA complexity this introduces is terrifying.
>
> Axel
>

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>

[Jaime Chen]

Hi there-
I saw this email to dev-gaia and just wanted to also cc: the group of people to continue this conversation.

Guillermo- I'm not sure how closely you work with our team, but we are actually quite aware of the fact that the product needs to be localized- our team is international and speaks multiple languages (French, Chinese, English, etc).

Matej is cc:ed who is the copy writer we work with. We do our best to follow our style guide here: https://docs.google.com/a/mozilla.com/document/d/19XbHvtThAUCwzyx_TXJHY7ZX8t99MxhZnZamWUcB158/edit though not all of those suggestions are possible.

I want to point out that this is a complex area and in fact not the sole responsibility of the UX team. We create wireframes which intend to accomodate longer strings if possible (or just use icons).

If strings do not fit, then the conversation should involve the copywriter, the developer, the UX designer and the localization team to figure out the best possible fix. Please refer to this example: https://bugzilla.mozilla.org/show_bug.cgi?id=908300

Let me know more questions.

Thanks!
Jaime

----
Jaime Chen
UX Manager & Design Strategist
Firefox OS, Mozilla

------------------------------

Message: 3
Date: Fri, 29 Nov 2013 15:19:16 +0100
From: Guillermo L?pez Leal <willy...@mozilla-hispano.org>
To: dev-...@lists.mozilla.org
Subject: [l10n] UX team, remember that Gaia NEEDS to be localized
Message-ID: <5298A264...@mozilla-hispano.org>
Content-Type: text/plain; charset="iso-8859-1"

Hi all,

This is a friendly reminder of a translator that is tired of shortening
strings in our translations that are perfectly understandable in
English, but that are impossible to understand in our language.

Keep in mind that space is really small, and I am sure that you have
tried to shorten the English strings to fit in that space, but usually
Latin languages (Spanish, French, Italian...) take more space to say the
same without loosing any meaning.

[Francesco Lodolo]

Il 02/12/13 04:00, Jaime Chen ha scritto:

> Guillermo- I'm not sure how closely you work with our team, but we are actually quite aware of the fact that the product needs to be localized- our team is international and speaks multiple languages (French, Chinese, English, etc).

Hi Jaime,
unfortunately I know exactly where Guillermo's mail -- and pain -- is
coming from.

You can measure how bad we're doing by looking at the dependencies of
this bug, more than bug 908300.
https://bugzilla.mozilla.org/show_bug.cgi?id=928174

Not sure if all Gaia developers are aware of the size of the problem,
even if the number of locales we're shipping is still pretty limited.
And 1.2 is our third release, we should have fixed most of this by now,
but we failed.

Some thoughts, not just on the truncation problem but on general Gaia
i18n, some of which I shared with :kaze in the past days.

*Check the strings, not just the code*
A first step would be to really check the English strings before they
land and are exposed to the localization process. I can give you some
examples

https://bugzilla.mozilla.org/show_bug.cgi?id=944869
https://bugzilla.mozilla.org/show_bug.cgi?id=944371
https://bugzilla.mozilla.org/show_bug.cgi?id=930417
https://bugzilla.mozilla.org/show_bug.cgi?id=927999
https://bugzilla.mozilla.org/show_bug.cgi?id=917198

The fact that I'm the one catching these -- my main language is Italian,
not English -- means that we need to fix something in the review
process, for example by assigning to strings the same importance of code.

*Stop reusing strings in different context*
If you think you're helping localizers by reusing the same string in
different contexts, you're not. Some locales use nouns in titles and
verbs in buttons, and the difference in font size and available space
between these two elements is huge on Gaia.

Again, this give you an idea of the size of the problem just for Settings
https://bugzilla.mozilla.org/show_bug.cgi?id=944749

Maybe using a naming scheme (XXX-label, XXX-button, XXX-header) could
help stopping developers from reusing strings, and would also mitigate
the lack of localization comments in .properties files.

Having a "coding style" for .properties file would be nice too, my eyes
hurt when I look at files like this one
https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/locales/settings.en-US.properties

*Stop changing strings without using new IDs*
Kudos to Pascal Chevrel for putting together this view in the last hours.
http://transvision-beta.mozfr.org/gaia/?locale=it#englishchanges

Check the last 3 strings and the kind of changes occurred between 1.1
and 1.2. How many locales will have picked up the change? For example
Italian did, Portuguese no
http://transvision-beta.mozfr.org/gaia/?locale=pt-BR#englishchanges

*UX: plan for flexibility*
I'm not talking about headers' font sizes and things that need to be
consistent in the whole system, but about applications' UI: stop using
English as a reference, design for strings that are at least 30% longer
than that.

Again, the following bugs are good examples
https://bugzilla.mozilla.org/show_bug.cgi?id=885946
https://bugzilla.mozilla.org/show_bug.cgi?id=943701

*Start testing Gaia in a different locale*
I suggested to :kaze that maybe an automatically generated pseudo-locale
could help for UI testing, but even if you don't speak the language you
may start using Italian to test your own work. It's usually fully
localized a few hours after English strings land in our Hg repository,
and about 25% longer than the original (similar is Spanish, while French
is about 32% longer, according to my not necessarily scientific
calculations).

Using a different language could help you spot UI problems as well as
non localizable strings (missing data-l10n-ids, or missing strings in
en-US properties files, I've seen both of these several times).

Francesco

[Ben Kelly]

On 12/01/2013 06:07 PM, Axel Hecht wrote:
> Sorry, but this horrible. The UX is stuff that should happen on the side
> of UX, and not on the side of localizers trying to work around design
> problems.
>
> We can't assume that localizers will manage the code creation you
> suggest here, and the QA complexity this introduces is terrifying.

Is there anyone from l10n who sits in on UX meetings? If not, should
there be? It might be a way to raise the visibility of the issue and
catch problems sooner.

Just a thought.

Ben

[Axel Hecht]

That's a good thing to have, yes.

We have something similar on desktop based on mozmill, but that uses
XUL's boxObject,
http://hg.mozilla.org/qa/mozmill-tests/file/13ca4bdc13c4/firefox/lib/localization.js#l99.
My html devtools foo isn't strong enough to know if that can be ported
to non-xul easily.

Some lessons learned:

Getting your tests to run on localized builds is work. On desktop, we
actually use a custom test suite. Sadly, they're cumbersome to write, so
test coverage is spotty. Don't compare to "OK", use only IDs or such to
navigate, etc.

Getting en-US to pass your test is hard. Desktop doesn't really, so
there are a few tricks in the tests to work around those, and to ignore
false positives.

Getting your tests to run needs infrastructure, of the non-trivial kind.

For desktop, the above are mostly in check these days, we're stuck at...

Getting reports for your builds. The data is at
http://mozmill-daily.blargon7.com/#/l10n for desktop, but you only get a
json blob out now. And there's no resources to fix that, and no idea how
the fix would look.

Axel

On 12/2/13 12:24 AM, Dale Harvey wrote:
> Seems like it would be possible for us to write a tool that ran integration
> tests in various locales and reported us hitting string overflows? not
> quite sure how it would be possible to detect them, but seems possible
>
>
> On 1 December 2013 23:07, Axel Hecht <l1...@mozilla.com> wrote:
>
>> On 12/1/13 9:49 PM, Andrew Sutherland wrote:
>>

[Axel Hecht]

That could be a good idea, I haven't found details on those meetings. If
anyone had pointers, we could give that a shot.

Axel

[Ben Kelly]

On 12/02/2013 11:42 AM, Axel Hecht wrote:
> On 12/2/13 3:19 PM, Ben Kelly wrote:

> That could be a good idea, I haven't found details on those meetings. If
> anyone had pointers, we could give that a shot.

Josh,

Do you know how Alex and l10n team could get more involved with the UX
process? Do you have regular meetings they could attend, etc?

Thanks!

Ben

[arky]

Hi,

Another related issue is the support for RTL(Right-to-Left) languages in
Gaia. You can view some of reported issues here[1].

We need to encourage the developers to understand how to write
applications that work seamlessly whether your using gaia in Italian or
Arabic. Creating a best practices documentation[2] is a good idea.

Testing your application in the language that you don't understand is
difficult. Adding a RTL locale like Arabic[3] to engineering builds will
allow gaia developers and UX team to quickly spot problems at an early
stage.

Cheers

--arky

[1] Meta tracker for RTL support
https://bugzilla.mozilla.org/show_bug.cgi?id=906270
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=938098#c7
[3] Arabic(ar) is most common RTL language on mobile phones and spoken
in following countries
(http://en.wikipedia.org/wiki/List_of_countries_where_Arabic_is_an_official_language)

[Guillermo López Leal]

El 02/12/13 00:07, Axel Hecht escribió:

> On 12/1/13 9:49 PM, Andrew Sutherland wrote:

> Sorry, but this horrible. The UX is stuff that should happen on the
> side of UX, and not on the side of localizers trying to work around
> design problems.
>
> We can't assume that localizers will manage the code creation you
> suggest here, and the QA complexity this introduces is terrifying.

Hi,

thanks Andrew for that suggestion. I didn't know that Gaia is able to
change CSS styles with properties files. I'm aware that it's possible
in Gecko l10n, but not with Gaia.

Anyway, I think that's really bad for us, localizers. Some of us know
CSS (just to change backgrounds and so on, nothing more!) and that will
be impossible to manage for every team. So I think this is a possibility
for some teams, but not for all. And adds an extra complexity to testing
and localizing.

But I have another question... Imagine we have a font-size of 30px for a
header, but that does not fit in Spanish, and we need to change it to
20px (extreme example). We will end up with different header sizes for
each section (in the worst case). What should we do? Keep the full
string with small text size? Keep the same text size with the entity
broken? Who should win? l10n or UX?

If you ask a localizer: "l10n should win, you must need to have a clear
translation". If you ask UX: "UX should win, there must be consistency
between all headers".

So this is a difficult question to answer.

And I support the idea of UX checking the possibility of every string to
add at least a 30% of characters for languages where strings are longer
(as Flod says, for example French). Is this possible for UX team?

BTW, I have seen that French team changed one style for the "Bookmark"
tab in Browser to enlarge the size. That makes the UI to show all three
buttons, but imagine that we need to change every single element in the
metabug Flod posted a few mails before this to make our translation
perfect (with imperfect UX).

Cheers,

Guillermo

[Andrew Sutherland]

On 12/05/2013 05:12 AM, Guillermo López Leal wrote:
> But I have another question... Imagine we have a font-size of 30px for a
> header, but that does not fit in Spanish, and we need to change it to
> 20px (extreme example). We will end up with different header sizes for
> each section (in the worst case). What should we do? Keep the full
> string with small text size? Keep the same text size with the entity
> broken? Who should win? l10n or UX?
>
> If you ask a localizer: "l10n should win, you must need to have a clear
> translation". If you ask UX: "UX should win, there must be consistency
> between all headers".

Given the current development cycles I think the most reasonable choice
is for l10n to win. By the time new strings are being localized,
non-blocker changes usually aren't allowed to get uplifted. And
frequently the only real solution for the problem is a more thorough
overhaul of the UI, which is definitively risky to uplift. We're still
very much putting out fires and playing catch-up and 1.3 is now
done-ish, so at least through v1.3, unless the uplift policy becomes a
lot more lax, fixes at the l10n level are the only realistic option.

For example, in the e-mail app we use the 'filters' building block
(http://buildingfirefoxos.com/building-blocks/filters.html) for the
search screen. This is unfortunately a bad idiom for textual labels,
especially with l10n figured in. Due to a font change somewhere along
the line, even our English strings are getting truncated:
https://bug946829.bugzilla.mozilla.org/attachment.cgi?id=8343203

In order to have feedback about truncated strings that have been worked
around without requiring tons of bugs to be filed using existing tools,
we can use something MozFR's transvision (http://transvision.mozfr.org/)
to find locales that have added entities that include "style" in the
name. And when we get around to automated tooling to detect overflows,
we could also just ignore any explicit style directives coming from l10n.

I think a major problem right now for the hack I propose is that a lot
of the automated localizing tools don't have a concept of an entity
that's added as part of the localization (which is reasonable). For
example, in https://bugzil.la/894696 I used the style trick there for a
Turkish localization on the search page, but I couldn't figure out how
to make Pootle support the entity and a needinfo asking for better
guidance was never fulfilled, so I just provided a pull request against
the raw file. About a week later, a new Pootle revision clobbered the file.

Andrew

[Axel Hecht]

On 12/5/13 6:18 PM, Andrew Sutherland wrote:

Right, each tool that's involved in the l10n process will advocate to
remove the hack again, and some will just do.

I'm not sure to which extent we can actually make good changes to the UI
with language dependent CSS, but if there is an opportunity, I suggest
to include language dependent CSS in the app CSS, and not rely on the
infrastructure to support that. There's the :lang() selector, so this
can be done cleanly in at least a CSS sense,
http://www.w3.org/TR/CSS2/selector.html#lang.

In gecko, we also have a global intl.css file which was introduced to
support hacks on a per localization basis. That didn't prove to be too
useful, though there's still a bunch of them having a bunch of content.
To which extent any of the rules in there still apply, I don't know. The
benefit of having a CSS file is two-fold, it can be shipped with
language packs (as opposed to centrally held language dependent rules),
and it's a file format that our l10n tools don't understand to begin
with, so it lives outside of the l10n processes for the most part.

We'd need packaging and optimization support in the gaia build process
for that to work.

Re https://bugzil.la/894696, I actually think this is a good example of
the limitations of the .style hack. AFAICT, your tweak makes the cropped
element visually different, whereas a per-app/page style could balance
the size and padding between all the elements, and keep a consistent
visual style among the tabs there, with just a horizontal shift or so.

Axel

[Julien Wajsberg]

Basically, moving more and more to Flex Layout should help (as the Flex
Layout obey the "dir=rtl" property).