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: ,

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:

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.

mockup

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: , ,

Photos from Fa’ la cosa giusta 2009

Fa' la cosa giusta 2009

You can see on Flickr the complete set of photos that I took yesterday at Fa’ la cosa giusta in Milan (Italy).

It was a real pleasure to see again in person the other guys from the Italian localization project (we are spread all over the country, so it’s quite hard for us to meet all together in one place), and also our international guest William 🙂

Thanks to all for the great fun day!

Technorati Tags: , ,

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: , ,

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: ,