Bad Localization Example (Java on OS X)

This is the dialog window that appears when you try to run a Java Applet on Mac OS X 10.5.7 with the last Java update (I’m running Java 1.5.0_19 according to this test).

Take a look at the checkbox:

• In Italian it’s “l’accesso” (definite article+noun), not “laccesso”. The same error appears in the first label, so I suppose they have some difficulties dealing with apostrophes. This problem was already there before the Java update.
• Applet’s name and author are gone, replaced by {0} and {1} (this started with the last Java update).

Here’s my questions:

• Who is to blame for this window? Sun (as I suppose) or Apple? Sure it’s not Mozilla’s fault, since the same thing happens with Safari 4.
• Is this happening only with the Italian localization of OS X? Are other locales affected as well?
• How can we try to fix that, since someone will think for sure that this is our (Mozilla localizers) fault?

Technorati Tags: java, os x, localization

I Hate Accesskeys

As usual, before the final release we’re doing a lot of QA work on our localized Firefox builds, and this includes a careful check on accesskeys. There are two different issues with accesskeys:

• use of a character not available in the label. For example: using “F” as accesskey for “Shiretoko” creates a label “Shiretoko (F)”. This can easily happen if you update the label and forget to correct the corresponding accesskey.
• duplicated accesskeys (two or more labels with the same scope share the same accesskey).

In the last 24 hours we found two duplicated accesskeys in the Italian build: the first one is quite hidden (you have to check for updates in the Extension manager and then click on the “More information” button), while the second one is located in the main window (Toolbar search). This last issue affects the en-US build (see bug 498840) and probably also other locales.

I think that we should really start to think about accesskeys and how to introduce automated tests.

The first step should be to create a standard naming convention (it’s not even mandatory, but it would make things easier): right now you can find accesskeys named like “label_accesskey”, “labelaccesskey” or “label.accesskey”. At this point, checking for external characters shouldn’t be a problem.

The real challenge would be to find accesskeys conflicts – using different tables to store all the accesskeys with the same scope – in particular in pop-up menus. Have you ever tried to select different parts of a web page (create a selection with images, links, images with links, text, etc.) and check how the context menu change? Doing this kind of checks manually is simply crazy

Technorati Tags: accesskeys, localization

Survey for Ubiquity localization

How can we localize this set of commands in Italian (see Mitcho’s post)?

1. search HELLO
2. search HELLO with google
3. translate HELLO from English to French
4. lookup the weather for PLACE
5. shop for SHOES with Amazon
6. email HELLO to Bill
7. email HELLO to ADDRESS
8. map PLACE
9. find HELLO
10. tab to HELLO or switch to HELLO tab

1. cerca HELLO

Italian uses the same order of English, so this one is easy.

2. cerca HELLO su google

First minor problem (see also this comment): do you search “on” Google, “with” Google or “in” Google? The form “cerca su” (“search on”) is probably the most used nowadays. Note that the object is placed between the verb (cerca) and the preposition (su).

3. traduci HELLO da inglese a francese

Removing definite articles maybe gives a little less natural feeling (“da inglese a francese” instead of “dall’inglese al francese”), but it still sounds good.

4. controlla meteo di PLACE
5. compra SHOES su Amazon

Same order and structure of English, just need to find the most appropriate verbs (for example, you “check” the weather or “display” weather conditions?).

6. email HELLO to Bill
7. email HELLO to ADDRESS

These two commands are quite problematic to localize:

• we don’t have a single Italian verb for “to email”
• you can “send (or write) an email to someone”, the tricky part is to include the object (HELLO)

If “HELLO” is an object (like a map, a selection or a link), the structure “send this by email to someone” is ok:

invia HELLO per e-mail a Bill/ADDRESS

What if HELLO is a text, like “email «good luck» to Bill”? In this case the proposed structure sounds weird, but honestly I can’t find a better structure (any suggestion out there?).

6. invia HELLO per e-mail a Bill
7. invia HELLO per e-mail a ADDRESS

8. cerca mappa di PLACE

Since we don’t have a single verb equivalent to “to map”, we can use something like “search map of”.

9. trova HELLO

Same order of English.

10. passa alla scheda HELLO

“Tab to HELLO” is almost impossible to translate, while “switch to HELLO tab” has a different order in Italian (equivalent to “switch to tab HELLO”).

This is the final result, hopefully with chances of improvement on 6 and 7

1. cerca HELLO
2. cerca HELLO su google
3. traduci HELLO da inglese a francese
4. controlla meteo di PLACE
5. compra SHOES su Amazon
6. invia HELLO per e-mail a Bill
7. invia HELLO per e-mail a ADDRESS
8. cerca mappa di PLACE
9. trova HELLO
10. passa alla scheda HELLO

1. search this with google
2. translate this to French
3. bookmark this tab

The only problem in these 3 commands is the lack of a single verb for “bookmark”, which can be changed to “add to bookmarks”. The correct form is “aggiungi questo ai segnalibri” (“add this to bookmarks”).

1. cerca questo con google
2. traduci questo in francese
3. aggiungi questo ai segnalibri

Technorati Tags: ubiquity, l10n

Localizer: Follow That Address!

A brief follow-up to the previous post: after the discussion held in mozilla.dev.l10n, a new pseudo account has been created in Bugzilla (see bug 484645) to track changes that affect the localization process in an earlier stage.

If you’re a localizer, maybe it’s a good choice to follow that account: in BugZilla’s Preferences, open the Email Preferences panel and add community@localization.bugs to the User Watching list.

Technorati Tags: community@localization.bugs

Why l10n should be involved in UI redesign

Take a look at this mock-up of the new Privacy panel: looks great, doesn’t it? But for me it’s just a l10n nightmare.

When you localize software, you have two possibilities (at least in Italian):

• be informal and use the second-person singular
• be formal and use passive forms and third-person singular

The second one is the obvious choice for professional translations, and we chose this path for our localization. This means that you should also try to avoid software personification: actions are done by (or with) the software, software’s name shouldn’t be used as a subject in sentences.

“Firefox will” is a bad choice for another reason: many languages don’t use auxiliary verbs to create future forms, so how can I translate that? Ok, I could try to find a suitable auxiliary verb, for example “deve” (must). “Firefox must: remember history/never remember history”. And there I’m stuck again: in negative forms, the “not” should go before the auxiliary verb:

• Firefox deve salvare la cronologia (Firefox must remember history)
• Firefox non deve mai salvare la cronologia (Firefox must never remember history)

The purpose of this rant is: please try to involve l10n in UI redesign, and try to land this massive changes before a string freeze.

Technorati Tags: localization, mozilla, privacy panel

D’oh!

That’s why I hate string freezes: from green to a billion strings missing in one second

Technorati Tags: string freeze

Thinking Ubiquity in Italian

Since I read this post about “Thinking Ubiquity in Portoguese” and Mitcho’s blog, I started asking to myself: what are the challenges of localizing Ubiquity in Italian?

Quoting from the same post (bolds are mine)

Since Ubiquity provides a natural language interface between the user and the computer, the way that the user interacts with the commands should feel natural at his language, conforming (although not strictly necessary) with the language’s grammar, and specially conforming with how the user thinks and expects to give commands in his own language.

Consider the verbs in this Jono’s post.

23 are verbs: bookmark, calculate, close, convert, define, delete, email, exit, help, hilight, map, print, redo, refresh, restart, save, search, tag, translate, undelete, underline, undo, zoom

Since you’re giving a direct order to the browser, verbs should be in imperative form (at least, in my mind there’s no doubt about this). For example: underline should be sottolinea (imperative form of sottolineare).

First problem: for some of those verbs there’s no Italian equivalent. Take for example bookmark or email: we don’t have a single verb to define this kind of actions, in most cases we use the form verb+noun (“add bookmark”->”aggiungi segnalibro”, “write email”->”scrivi email”).
Some English verbs are adapted to Italian using the first conjugation (“to schedule”->”schedulare”), but these forms are simply awful

Second problem: some verbs are not easy to understand out of their typical context. Think about undo and redo: as menu items these two actions are universally translated as annulla and ripeti,  but to be really “natural” we should at least add a noun (“Undo action”->”Annulla azione”, “Redo action”->”Ripeti azione”).

The first problem (the biggest one) could be solved using overlord verbs (see this proposal): “google”->”search google”->”cerca in google”.

What are the possible shortcomings of this approach? The first I can think of: what if the English overlord verb is not suitable for another language? For example, the verb “make” is quite difficult to translate (too generic): “to make” could be “fare”, but “fare grassetto” (“make bold”) doesn’t make any sense, people would use more specific verbs:

• make bold ->  trasforma in grassetto (sounds like “change to bold”)
• make page editable -> rendi pagina modificabile

Two different localized verbs for a single overlord English verb. Is the Ubiquity’s parser able to manage this situation?

Technorati Tags: ubiquity, localization, i18n

About Localization-QA survey results

This post started as a comment on Seth’s blog, but the resulting thoughts were too long for a comment

Conclusion:  Litmus manual tests are important and hard to automate to replace visual verification.  Has everyone played with Litmus?

I agree, Litmus tests are important (and, to be honest, quite boring) but they’re not enough. For example, one of the steps we need to do in order to ensure the quality of our localized builds is:

• Open every menu and find access keys conflicts.
• Open every window and find cropped dialogs or access keys conflicts. Sometimes you don’t even know how to check some strings, for example because it’s impossible to manually trigger that event (it took me weeks to find the “CrashMe” extension to check Breakpad’s localization).

It sounds like a task suitable for automation: create an extension that make screenshots (in png format) of every menu and window and save them in a folder (I remember something similar from Axel, but it was a limited set of windows). Since we have to check all these items anyway, a similar tool would greatly simplify our QA work: finding cropped dialogs would become a matter of seconds.

Conclusion:  We might need to blog to demystify the bug filing process for l10n volunteers.  Or, provide easy tools like bug-by-email templates.

Let’s take a step back: is BugZilla the best tool to discuss/improve localizations? For Italian we use our forum for this purpose, in the past we used a mailing list, and the discussions can reach a considerable length (this is the thread about Fx3.1, and it’s 25 pages long right now): one single bug would be difficult to follow, more bugs would probably make my work as a localizer more difficult.

While BugZilla it’s a valuable tool for released (and frozen) versions (you eventually need a patch+approval to fix the problem), I don’t think it’s the best solution for nightly/trunk localization.

Another problem: as far as I know, we’re not clearly telling people how they can report errors or improve the localization, we treat these like normal bugs. Maybe a landing (and localized) page would be a better choice: each team would be free to choose their tools – for example a mail address, a forum section, or even BugZilla if they want – and help users to find the right communication channel.

Conclusion:  We might have to provide a generic blue-print for effective test planning for any locale, indicating what are the key l10n steps in test planning.

This sounds reasonable (as a suggested path, not mandatory).

Conclusion:  We might need a third-party QA service to help lead volunteer L10N test activities.

“A third-party QA service” means that a third-party entity checks the localization and reports errors? This sounds dangerous and, potentially, time wasting: to check a localization you need to know a lot of the underlying decisions (for example why we choose to translate some words in a specific way, why we use the third person in verbs and not the second, etc.) and QA criteria. Both third-party QA and localization have been done in the past, and the results were far from good.

Technorati Tags: l10n, qa