1023013 - Vietnamese Firefox 29.0 menu bar - (f) - alt-f won't work

Status: RESOLVED DUPLICATE of bug 1024363

(Mozilla Localizations :: vi / Vietnamese, defect, P2)

Description

[Nguyen Vu Hung (Nguyễn Vũ Hưng)]

Attachment: Firefox screenshot - menu bar - (f) - alt-f won't work.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140428193838

Steps to reproduce:

Environment:
- Ubuntu 12.04, x64
- Bundled Firefox 29.0


Actual results:

Top menu shows:
- Tệp (f)
- Trang ưa thích (b)



Expected results:

Top menu shows:
- &Tệp
- T&rang ưa thích

Comment 1

[Ha-Duong Nguyen]

It was agreed in the past among active Vietnamese localizers that accelerators should be consistent in both English and Vietnamese.  Thus expected accelerators should be "f" for File and "b" for Bookmarks respectively.  This could certainly be changed if it causes inconveniences for users.

Translation committed in Locamotion[1].  Please test.

Best,
Duong "Yang" Nguyen

[1] http://mozilla.locamotion.org/download/vi/firefox/browser/chrome/browser/browser.dtd.po

Comment 2

[Minh Nguyễn]

(In reply to Duong H. Nguyen from comment #1)
> It was agreed in the past among active Vietnamese localizers that
> accelerators should be consistent in both English and Vietnamese.  Thus
> expected accelerators should be "f" for File and "b" for Bookmarks
> respectively.  This could certainly be changed if it causes inconveniences
> for users.

How unfortunate. The original Firefox localizers (loveleeyoungae and I) agreed to never translate keys or modifiers but to /always/ translate accesskeys. An accesskey in Mozilla-based applications is what Windows calls a keyboard accelerator and what the Mac used to call a mnemonic. It's the letter that gets underlined when pressing Alt in Windows.

The File menu label is currently "Tệp (&f)". It should be "&Tệp". If the accesskey of a menu title were intended to be F in every language, Mozilla would've hard-coded that behavior instead of making it localizable. If it were supposed to be possible to set the accesskey to a letter not in the title, the .po file would list labels and accesskeys in separate strings instead of relying on a positional ampersand. But now, with every passing build, I'm seeing ugly parentheses after more and more menu items in Firefox on the Mac. And Mac OS X doesn't even support accesskeys anymore!

Sensible accesskeys are important for accessibility on Windows, and what we've got now is hideous and inconsistent. But don't take my word for it. Here's the Mozilla documentation on accesskeys:

<https://developer.mozilla.org/en-US/docs/XUL_Accesskey_FAQ_and_Policies#How_do_I_pick_an_accesskey_letter.3F>
<https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/Accesskey_display_rules>

Accesskey only go in parentheses after the label in non-Latin alphabets, like Japanese. There is rarely a need to do that in Vietnamese. (I may have done it once or twice to avoid duplicates.)

Comment 3

[Ha-Duong Nguyen]

Accelerator is the term used in GNU/Linux systems, particularly GTK applications.  Both Windows and Mac OS X use mnemonic.

Indeed, the decision should be available somewhere for newer contributors to follow.  The most recent one (i.e. keeping the accesskeys as in English) was made about 2 years ago in an offline translation sprint by a bunch of active localizers among which some are still active.

That said, it doesn't really matter whether or not accesskeys are intentionally fixed, it's about having the same experience between English and Vietnamese users vs. clean UI.

The links you provided did not mention rules for accesskeys in languages that use Latin alphabets but left the decision to localizers.  This is going off-topic now.  Please file another bug or open a discussion if you think it's necessary to change.

Cheers,
Duong "Yang" Nguyen

Comment 4

[Minh Nguyễn]

(In reply to Duong H. Nguyen from comment #3)
> The links you provided did not mention rules for accesskeys in languages
> that use Latin alphabets but left the decision to localizers.  This is going
> off-topic now.  Please file another bug or open a discussion if you think
> it's necessary to change.

See bug 1024363.