Community
Participate
Working Groups
Created attachment 200716 [details] Screenshot I20110729-0200 (4.2), OK in I20110729-1200 (3.8) In 4.2, the Keys preference page contains untranslated keys like "%command.arrangeWindows.name".
Interesting: I don't see this on Windows 7.
AFAIK, these 4 commands are in the org.eclipse.ui.cocoa fragment.
Created attachment 201856 [details] Patch against CommandProcessingAddon to localize strings (In reply to comment #2) > AFAIK, these 4 commands are in the org.eclipse.ui.cocoa fragment. They're also defined as necessary in org.eclipse.e4.ui.workbench.renderers.swt.cocoa, which provides native Eclipse 4 support for the equivalent functionality from the legacy org.eclipse.ui.cocoa fragment. The root cause of this issue is that there is a discrepancy in handling internalized strings between legacy commands defined in plugin.xml are handled vs e4 commands defined programmatically. But in org.eclipse.e4.ui.workbench.renderers.swt.cocoa, these commands are created programmatically (only if not present) using localized keys where appropriate. This makes sense from the Eclipse 4 perspective as we now support being able to change locales on the fly (and even on a per-model element). These keys are being properly translated when shown in the UI (check the Window menu and you should see "Bring All to Front", "Minimize", and "Zoom", all provided through this fragment). But these strings are not being translated by the KeysPreferencePage before being presented. Legacy commands loaded from plugin.xml are translated immediately. I think the real issue here is that the legacy commands that are spoofed-up to correspond to the Eclipse 4 commands should have their strings put through translation. I've attached a patch to the CommandProcessingAddon that localizes command name, command description (which wasn't being passed previously), category name, and category description when creating legacy objects from model commands and categories. Note that the #localize() helper is required as LocalizationHelper#getLocalized(String,MApplicationElement) can return null. Paul, could you please verify? I'll commit this with some other minor fixes.
This patch looks good to me. Please update the copyright year when you release the change to R4_development, Brian. Thanks!
Committed to R4_development
Quick scan against key bindings for M4 reveals no untranslated keys
