Last Comment Bug 266663 - need per-platform entities for menu item labels
: need per-platform entities for menu item labels
Status: NEW
: l12y
Product: Firefox
Classification: Client Software
Component: Menus (show other bugs)
: Trunk
: All Mac OS X
: -- normal with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 266678 (view as bug list)
Depends on:
Blocks: 259167 268785
  Show dependency treegraph
 
Reported: 2004-10-29 03:23 PDT by Martin Creutziger [:MMx]
Modified: 2013-02-27 16:21 PST (History)
13 users (show)
benjamin: blocking‑aviary1.0-
benjamin: blocking‑aviary1.5-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Martin Creutziger [:MMx] 2004-10-29 03:23:15 PDT
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 [:bsmedberg] 2005-01-06 03:52:33 PST
Patches are highly encouraged, but I'm still not going to block for this.
Comment 2 Josh Aas 2005-03-11 01:31:51 PST
taking
Comment 3 Marek Stępień [:marcoos, inactive] 2005-11-05 04:45:49 PST
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 2008-01-30 13:42:18 PST
not late-l10n for fx3
Comment 5 Finn Sørensen 2010-10-05 01:36:18 PDT
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] 2010-10-05 01:55:14 PDT
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: gavin@gavinsharp.com] 2013-02-27 16:21:14 PST
morphing this to be about the general problem
Comment 8 :Gavin Sharp [email: gavin@gavinsharp.com] 2013-02-27 16:21:20 PST
*** Bug 266678 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.