need per-platform entities for menu item labels

NEW
Unassigned

Status

()

Firefox
Menus
13 years ago
5 years ago

People

(Reporter: MMx, Unassigned)

Tracking

(Blocks: 1 bug, {l12y})

Trunk
All
Mac OS X
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -
blocking-aviary1.5 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
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.
(Reporter)

Updated

13 years ago
Flags: blocking-aviary1.0?
(Reporter)

Updated

13 years ago
Summary: Need a new entity in global-platform for l12y → Need a new entity in global-platform for "File"
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Target Milestone: --- → Firefox1.1
Version: 1.0 Branch → Trunk
(Reporter)

Updated

13 years ago
Blocks: 268785

Updated

13 years ago
Flags: blocking-aviary1.1?
Patches are highly encouraged, but I'm still not going to block for this.
Flags: blocking-aviary1.1? → blocking-aviary1.1-

Comment 2

13 years ago
taking
Assignee: firefox → joshmoz

Updated

12 years ago
QA Contact: bugzilla → menus
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.

Updated

10 years ago
Assignee: joshmoz → nobody

Comment 4

10 years ago
not late-l10n for fx3
Keywords: late-l10n
Hardware: PowerPC → All
Target Milestone: Firefox1.5 → ---

Comment 5

7 years ago
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

7 years ago
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
Summary: Need a new entity in global-platform for "File" → need per-platform entities for menu item labels
Duplicate of this bug: 266678
You need to log in before you can comment on or make changes to this bug.