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.

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

taking

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.

not late-l10n for fx3

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...

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.

morphing this to be about the general problem