266663 - need per-platform entities for menu item labels

Status: NEW

(Firefox :: Menus, defect)

Description

[Martin Creutziger [:MMx]]

On MacOS X, the menu "File" is sometimes differently translated then on Win/Lin. 
e.g. in German: 
Win/Lin: "Datei"
Mac: "Ablage"

We already had several Mac users complaining about this, so this should be changed.
Now that the "Aquafication Release" has been canceled, this should block 1.0.

Comment 1

[Benjamin Smedberg]

Patches are highly encouraged, but I'm still not going to block for this.

Comment 2

[Josh Aas]

taking

Comment 3

[Marek Stępień [:marcoos, inactive]]

The problem is that it's not limited to the File or View menus (266678). The Edit menu is called "Edycja" under Polish Windows and Linux and "Zmiany" under Mac OS X, while File menu is called "Plik" on all systems.

So adding a special Mac entity for the "File" menu makes sense only if we introduce special Mac entities for *all* other menus.

Comment 4

[chris hofmann]

not late-l10n for fx3

Comment 5

[Finn Sørensen]

Would it add much overhead to the Mac build to have it look for Mac-specific strings when looking up a string?

Examples (_not_ serious ones, but to clarify concept) -

current .dtd file:
<!ENTITY  brandShortName        "Firefox">
<!ENTITY  logoCopyright         "Firefox and Firefox logo are trademarks belonging to Mozilla Foundation. All rights reserved.">

new .dtd file:
<!ENTITY  brandShortName        "Firefox">
<!ENTITY  brandShortName_mac    "iFirefox">
<!ENTITY  logoCopyright         "Firefox and Firefox logo are trademarks belonging to Mozilla Foundation. All rights reserved.">
<!ENTITY  logoCopyright_mac     "Firefox and Firefox logo are trademarks belonging to Mozilla Foundation. All rights reserved. The letter i on courtesy loan from Apple.">

current .properties file:
brandShortName=Firefox

new .properties file:
brandShortName=Firefox
brandShortName_mac=(you get the point)


I would suggest a patch if I could, but my skills in COMAL80, BASIC, PHP and 6502 ASM doesn't feel adequate here, thou I don't think the code should be all that big a problem to do if one has an idea about where and how in the files. 

Overhead on runtime performance shouldn't be hugely affected either, but ok here I'm on thin ice and just guessing - probably depends a lot on how its done code-wise and what it looks up first (dep. on how its even done currently). 2 language file string lookups for each string would probably cost on performance where we want it to be faster, it would obviously be better with only one lookup - if this is the way its done now at runtime.

Or could this be done at lang pack build time, with the Mac lang build(s) replacing non *_mac strings with *_mac strings where these occur, removing the _mac part for the entity, for that OS pack alone - and get around all performance worries the easiest way?

Solving this bug would fix these quite minor but numerous Mac language inconsistencies for languages (from what I'm told - far from exhaustive list I'm sure) da, de, fr, it, pl and maybe bring ja from 2 separate builds/translations back to one.

I don't know if this suggestion is feasible at all, and am aware that it is extremely unlikely to make it into 4 anyway, but it would be good to get this ball rolling along and maybe tie this additional layer in with current/future l12y efforts, like the Polish grammatical issues. Just shooting off ideas in the vain hope someone sees the light and writes a patch...

Comment 6

[Axel Hecht [:Pike]]

There has been limited thought about that as part of l20n. The right forum to discuss this would be http://groups.google.com/group/localization-20.

On the current platform, your proposal would likely require hacking expat core code, which I don't see anyone wanting to do. Also, mac being special is just one case of platform dependent strings, too.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

morphing this to be about the general problem

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

Can we close this now with Fluent and PLATFORM() ?

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

Do we know if localizers are using PLATFORM() for this type of problem? Is there any outreach we can do? We can otherwise close this but I want to make sure that we have made the Firefox product better now by having the correct terms in use.

Comment 11

[Francesco Lodolo [:flod]]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #10)

Do we know if localizers are using PLATFORM() for this type of problem? Is there any outreach we can do? We can otherwise close this but I want to make sure that we have made the Firefox product better now by having the correct terms in use.

I think the outreach is a separate issue, very few locales are using Fluent's asymmetry to their advantage.

Also, noting that 15 years have passed since this bug was filed. Maybe changing menus in Firefox might not be such a great idea, because users are used to them by now, and care about that more than about consistency with the OS.