603252 - Platform specific ellipsis char should be honored on menu and buttons

Status: RESOLVED WONTFIX

(Core :: Internationalization: Localization, defect)

Description

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Ellipsis (…) is used extensively in menus and buttons entities. They should in fact obey platform specific ellipsis (intl.ellipsis) specified in 

/toolkit/chrome/global-platform/(win|unix|mac)/intl.properties

by reference to that entities, or programmatically added (beware of RTL language for latter solution)

intl.ellipsis is almost useless without menus and buttons follows it, even if some function do need it, in order to keep everything consistent, localizers were force to set ellipsis across platform to the same one.

FYI:
* Apple uses U+2026
http://developer.apple.com/library/mac/#DOCUMENTATION/UserExperience/Conceptual/AppleHIGuidelines/XHIGMenus/XHIGMenus.html#//apple_ref/doc/uid/TP30000356-TP6
* GNOME uses "..."
http://library.gnome.org/devel/hig-book/stable/menus-design.html.en#menu-item-types
* KDE uses "..."
http://developer.kde.org/documentation/standards/kde/style/menus/index.html
* Windows uses "..." in Explorer, etc. No HIG document available.
* Mozilla uses U+2026 in en-US strings.

In some systems (e.g. Ubuntu), "..." will be rendered as U+2026 by means of font kerning. Yet, we should not rely on this kind of feature.

On zh-TW Windows, which uses PMingLiu as system font, U+2026 is rendered on the middle of the character height, looks very different than "...", which is on the baseline, used by other programs.

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Did some digging through Bugzilla:

bug 373623 is the bug that convert all dot-dot-dot to U+2026, mainly on the ground of accessibility.

bug 400237 comment 3 documented similar issue on Japanese Windows regarding U+2026 is being rendered as MIDDLE DOT.

Comment 2

[Tim Guan-tin Chien [:timdream] (please needinfo)]

bug 403484 was the bug that added intl.ellipsis

Comment 3

[Axel Hecht [:Pike]]

Yes, right now, there's not platform-dependent way to denote the ellipsis char (in the sense of "you'll need to do more...") in menus or buttons.

The placement of those is non-trivial, pa-IN is just moving the ellipsis into the strings themselves, as they feel that makes more sense grammatically.

Tweaking the font might be an interesting path, not sure how that impact a11y.

Adding some generic logic is likely cumbersome, too, who'd want to write out 
<!ENTITY print "Print&ellipse;">
every time?

I don't see a slick path in l20n for this, too, fwiw. Yeah, we could make a consistent variable, but you'd still had to explicitly reference it each time.

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

CCing Peter, the current zh-TW l10n owner.

Do you think this is some thing we need to improve in the i18n process? 

When I file this bug 2 years ago, my problem was that Mozilla software, only one kind of ellipsis can be used for all platforms -- Use "..." will make the UI look inconsistent to other programs on Mac, and use U+2026 will do the same thing to Firefox on Windows.

It seems that no one complains but me over the years.

Comment 5

[Gordon P. Hemsley [:GPHemsley]]

See also discussion in bug 488433 comment 2 about platform-specific ellipsis. (And the rest of the bug for intl.properties in general.)

Comment 6

[Francesco Lodolo [:flod]]

Tentatively closing this as WONTFIX. I don't see ourselves changing all strings with ellipsis, and provide multiple variant per platform. Feel free to reopen and move if you disagree.