RE: Edit menu localisation, default application menu
RE: Edit menu localisation, default application menu
- Subject: RE: Edit menu localisation, default application menu
- From: Lee Ann Rucker <email@hidden>
- Date: Sat, 11 Jul 2015 15:50:47 +0000
- Thread-topic: Edit menu localisation, default application menu
There are some that it will translate for you - Show/Hide Toolbar, for one. If you have "Show Toolbar", it'll swap in "Hide Toolbar" for you. However! If your translation of Show doesn't match, it won't swap in the translated Hide. This is easy to fall into if your localizers don't phrase it the way Apple did, or Apple changes their translation between versions and your app supports both.
The solution is simple - leave the text for toggleToolbarShown: blank. Then Apple will provide both Show and Hide for you in all the languages you support.
________________________________________
From: cocoa-dev-bounces+lrucker=email@hidden [cocoa-dev-bounces+lrucker=email@hidden] on behalf of Uli Kusterer [email@hidden]
Sent: Saturday, July 11, 2015 2:03 AM
To: Aandi Inston
Cc: cocoa-dev
Subject: Re: Edit menu localisation, default application menu
On 11 Jul 2015, at 09:39, Aandi Inston <email@hidden> wrote:
> It turns out, and I'm sure this will surprise nobody but me, that for the
> copy/paste/cut keyboard commands to work in Cocoa my app needs to have a
> suitable Edit menu with copy/paste/cut menu items and keyboard equivalents.
> My question is about localisation. The app is localised via its own string
> files.
In general I recommend using Apple's localization mechanisms where possible. In particular, use unique keys for each bit of text you localize, don't use the English strings. Words in languages are like circles in a Venn diagram, they overlap, but are rarely identical. Therefore, it's very easy to mis-translate something by using a translation that is correct in one context and nonsensical in another, because the other language would use a different word.
> Clearly I can add Edit/Copy/Cut/Paste to the strings for
> translation.
>
> But is there a better way to display a suitable Edit menu and use the
> locale standard translation for these names?
There aren't any standard translations provided by the OS. At some point Apple offered a set of standard localizations for download from its web site, but you have to copy those and provide them in your application bundle yourself, there is no automatic standard translation accessible to developers. I don't know if they're still available, I can't find anything since they redid the web site.
> Related: I observe that, even if I replace the [application mainMenu], that
> the menu which is then displayed has fixed, and localised, entries under
> the app name. That the title of the first menu is ignored and the contents
> merged with the standard ones. Old news I'm sure, but I can't find where
> this behaviour is documented, and what surprises it may have. Sometimes a
> "quit and leave Windows" or similar item appears, for instance. Can anyone
> point out what I should be reading?
There are variants of certain menu items that show when you hold down modifier keys like the Option/Alt key or the Command key. I think the menu item you mention is "Quit and Keep Windows" which is shown when you hold down option and comes from state restoration. It means that the app will behave like when you do a restart, where all open windows will be saved and the app will be re-launched after a restart in the same state it was in before, instead of how it happens when the user quits it, which will not restore window state.
I don't know where this is documented (beyond the info you can find in Apple's Macintosh Human Interface Guidelines, which describe what menus and items you should have and what they should do, IIRC), but numerous small behaviours like that have crept into the OS as Apple added system-wide features, but of course all applications' XIB files still contained the old menu layouts. Instead of a main menu with submenus, Apple turned the main menu into a menu bar when it bought NeXT, added a system-wide Apple menu, made the first menu that contains application-management menu items show the application name in boldface as its title, added the "Start Dictation" and "Emoji & Symbols" menu items to the Edit menu (neé "Special Characters…"), inseted a search field at the top of the Help menu …
It gets even funnier the farther you go back. E.g. the menu bar code was written for Carbon and shared with Cocoa (hence the utter nerfing of NSMenuView), and classic MacOS didn't have a Apple menu like we have today, and its application menu had the Apple logo, and the help menu used to be an icon like the Spotlight icon on the right side of the menu bar. So if you, today, launch a Cocoa app and bring up an alert before the menu bar has been created (e.g. from inside application*Will*Launch:), the system will see that the menus are empty, and will create standard Carbon Apple, application and Help menus for you. If you then afterwards load your menus, you will end up with two Help menus.
In short, it's a fun mess, but in general it Just Works(tm) and you don't have to worry about it. Just create menu items with the same actions and tags as the system-provided ones, and usually Cocoa will pick up that they're there.
Alternately, the easiest and most reliable way to get standard menus is still to use a XIB. Once you've loaded a minimal standard menu from your XIB, you can always insert and remove menu items as desired.
Cheers,
-- Uli
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden