This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
To reproduce, 1. right click on an item in Explorer (e.g. right click on a file in Filesystems tab) The popup menu does not show any mnemonic keys, that is letters with under-bars. Though some "&" are defined with those labels in openide/actions/Bundle.properties.
Jano could you please look at this bug.
It is as designed. NB context menu items don't have mnemonics. '&' characters are ignored intentionally. One of a reasons is described at http://a11y.netbeans.org/a11yFAQ.html Q: Do items in the context menu require mnemonics? A: No they do not and please do not assign mnemonics to context menus. We discourage using mnemonics in the context menus because there is a swing problem that does not shift focus between items with the same mnemonic in a menu. The context menu is generated dynamically in NetBeans so there is no way to guarantee that all items will have unique mnemonics. Keyboard access via Shift+F10 (to open) and the arrow keys is sufficient for making the context menus accessible.
When the same message is used between the main window's menu and the context menu of the explore, a mnemonic key in a localized message cannot be ignored. For example: Copy=&Copy <-- English Copy=japanese-copy-message(&C) <-- Japanese In the japanese message case, a mnemonic key is put at the end of message. As attached snapshot, mnemonic keys such as "(C)" are displayed in japanese messages. In order to fix this problem, please assign the different message ID between the main window menu and the context menu. For example: Copy_main=&Copy Copy_context=Copy Copy_main=japanese-copy-message(&C) Copy_context=japanese-copy-message Please examine message changes. Thanks, Yuko
Created attachment 5939 [details] I have attached a snapshot of explore.
I agree that this is a bug. We should either display underline mnemonic characters or provide different bundle values for popup menus and regular menus. And what about tooltip of copy action in the toolbar. How does it look like in Japanese? It doesn't make sense to display mnemonic chars in tooltips, right? Owner of actions, please evaluate.
Set target milestone to TBD
I must say that not only Japanese localization is affected by this issue, Russian and Chinese (recently started) too.
Cf. issue #26640. Re. tooltips: an action can specify a tooltip, otherwise it should not have one.
Can someone clarify if this is a real issue or not ? In reading comments below, one comment mentions that mnemonics not meant to be in explorer but others seem to indicate that it is an issue. If mnemonics in english locale can be used in these areas at all, but not in localized locale, I think it would be an issue. ken.frank@sun.com
Ken, IMO this *is* real issue, exactly as you said. After some research, I've learned following, which Jesse & Yarda knew for ages: Currently we have extended support for '&' chars signalizing mnemonics in following ways: If you specify in bundle string "text&C", where C is some non-ascii char, it's possible to define mapping from C to some ascii char which will be used as mnemonic. Non ascii char will be underlined on jdk 1.4, or coupled mnemonic ascii char will be underlined using ("underlined char") construction on jdk 1.3. Important is that only thing you're required to do is to provide bundle string "te&Cxt" and mentioned mapping. Question is, if it is possible and desirable in japanese to define mapping between non ascii chars which should be underlined and ascii chars that are actual mnemonics, so that mnemonics are still usable, it means that users can easily guess what key to press if they see underlined japanese char. Maxym showed us that in Russia it is like that. In other case, there's possibility to enhance mapping to include information *not* to underline native char, but always show () convention. Final point is that if mnemonics are specified using only & chars in text, they are skipped and not shown in popup menus, which is what we want here. Another new information is that jdk 1.4.1 should finally support mnemonics collisions, so it would be perfectly possible to enable mnemonics even in popups, which would solve problem as well (for 1.4.1 and later).
David, I think our localization center can comment more, but it was my understanding that only alphanumeric for mnemonic was fine for localized product (and perhaps preferred in cases where not all keybds might have localized setup). So for the solving of this issue, assuming this area used the '&' mechansim, it could be sufficient that every bundle entry have the '&' as part of it, since if it is omitted, that is where the problems are; even if product can use multibyte for mnemonic, that is not what is desired in this case, but to use same alphanumeric as base product. ken.frank@sun.com
Consistent use of the I18N keyword.
I'm not sure I've followed all of this, especially Ken's comments, but I think I can try to summarize some things. 1. Historically we avoided mnemonics in context menus due to a Swing bug. This is now fixed as of 1.4.1. My recommendation: show mnemonics in context menus. 1.4.1 users will be happy (faster access than with arrow keys in many cases), and 1.3.1 users who cannot upgrade should not be harmed - at worst, if two context menu items share a mnemonic, it will only work for one of them, so they should just use arrow keys. Of course we could enable context menu mnemonics just for JDK 1.4.1 and later. 2. Contrary to what jf4jbug said before, please DO NOT use different labels for the same action just to support mnemonic and no-mnemonic use cases. This is not necessary. Always assign a label that includes a simple &-based mnemonic. Possible styles: # English (generally, Latin characters): # Mnemonic display: English _T_ext # Plain display: English Text LBL_myaction=English &Text # Japanese (generally, non-alphabetic characters): # Mnemonic display (non-ASCII chars shown as '#'): ######## (_T_) # Plain display: ######## LBL_myaction=JaPaNeSe\u1234\u5678 (&T) # Russian (generally, alphabetic non-Latin characters): # Mnemonic display (JDK 1.4): #####_#_## # Mnemonic display (JDK 1.3): ######## (_T_) # Plain display: ######## LBL_myaction=RuSsIaN&\u0123\u0456 "Plain display" should of course be used for the tooltip automatically. All these distinctions should be handled for you transparently if you use standard SystemAction's, or more precisely org.openide.awt.Actions bridges. The distinction between alphabetic and non-alphabetic scripts is whether or not it is likely that the characters may correspond directly to a keycode. Clearly for Japanese it will not, but Maxym says that for Russian typically it will, and JDK 1.4 can handle it correctly. IMO all that needs to be done in core is to turn on mnemonics for context menu items by default under JDK 1.4.1+. Localizers should review their action labels for correct use of conventions.
I agree with Jesse and I'm going to make his suggested change for 3.5.
In Russia and Ukraine (not sure for other countries with Cyrillic alphabet) Keyboard layout, i.e. Cyrillic char <-> Latin char mapping, is standardized by RST - Russian Federation Standard (for Russian keyboard) and DSTU - Ukrainian State Standard (for Ukrainian keyboard). The computer hardware resellers are not allowed to sell unlicensed (not conforming to the standards) keyboards. I even remember some news about Dvorak keyboard not permitted to be sold in Ukraine, because it breaks this Cyrillic<->Latin chars mapping. I could search for the standard, but I don't feel it's necessary, and don't think you'll understand it (it's in Ukrainian language).
Checking to make sure that this solution does not preclude localization to use only ascii characters for mnemonics (which is what our localization center does). Also want to make sure that the placing of the '&' is task for developer of the module, not the localization center. Comments below are unclear to me on both those questions. ken.frank@sun.com
-> Ken. "Checking to make sure that this solution does not preclude localization to use only ascii characters for mnemonics (which is what our localization center does)." - of course, look at my Japanese example again. "Also want to make sure that the placing of the '&' is task for developer of the module, not the localization center." - not sure what you mean. Obviously placement of the ampersand in the English default bundle value is a job for the developer. The localizers are then responsible for providing a text label including an ampersand somewhere, in the localized bundle. If the localizer is Maxym, for Russian, he will want to select an appropriate Cyrillic character to use as a mnemonic. In the case of the Sun Japanese localization team, they could simply use the syntax I quoted for Japanese, which would use the same mnemonic character as in English. They are free to select a more mnemonic mnemonic than that, of course, but then they would need to check for conflicts. BTW: http://www.netbeans.org/download/dev/javadoc/OpenAPIs/org/openide/awt/Actions.html#cutAmpersand(java.lang.String) http://www.netbeans.org/download/dev/javadoc/OpenAPIs/org/openide/awt/Mnemonics.html#setLocalizedText(javax.swing.AbstractButton,%20java.lang.String) -> Dafe: See openide/test/unit/src/org/openide/awt/MnemonicsTest.java, which should be improved to cover all the use cases I listed. Right now it only checks a couple of things. If you want help expanding this test suite, just ask me.
In the case of Japanese l10n, Japanese message uses the same mnemonic character as English message. We do not use multibyte character as mnemonic key, and we do not change the mnemonic character because we cannot prove all mnemonic keys in all windows are unique. In the past release, Japanese messages in context menues had mnemonic keys though mnemonic keys did not work. This bug seems to be fixed with JDK 1.4.1, so if all english messages in context menues have correct &-based mnemonic characters, I think Japanese l10n has no problem. Thanks, Yuko
Assigned to new owner.
It's obsolete issue for now, IDE runs on jdk1.4.2 and higher. o.o.awt.Mnemonics supports alos localized mnemonic.
Uh, isn't the original issue that mnemonics are missing in the context menu? Looking at a current build, the popup menu for a Java class shows no mnemonics - except for the Refactor submenu, an anomaly.
I guess this won't be fixed for NB4.0 , please evaluate again. BTW: I think this one is WONTFIX
This is not WONTFIX, this is still a valid problem and it needs to be addressed (IMHO).
Well, will be considered in promoE timeframe, should be discussed with UI team if display mnemonics in context-menus.
Didn't be managed in NB4.1. So, targeted to NB4.2.
Too late for NB5.0, please reevaluate.
I have still some troubles with this issue. Could someone restat the defect? IMHO it works for me: Java, Project, CVS submenu etc. can display mnemonics. If no response I'm going to close as worksforme.
It seems that some context menu items (and submenus) have mnemonics and others do not. E.g. on a package node: "_F_ind" but "CVS >". On a project "Properties" but on a Java source "_P_roperties". Probably need Jano or someone to review existing context menus and file specific bugs where mnemonics are thought to be missing or inconsistent. The main bug (that mnemonics did not appear by default if you just made a SystemAction with an '&' in its display name and added it to a context menu) seems to be a dupe of issue #40801, fixed a year ago: http://www.netbeans.org/source/browse/openide/src/org/openide/awt/Attic/Actions.java?r1=1.107&r2=1.108&hideattic=1
Yes, the mnemonics should show up but only if the user invokes contextual menu with Shift-F10. They shouldn't be visible if the user invokes contextual menu using mouse. That's how contextual menus behave on WinXP.
Re. distinction between mouse and S-F10 invocation - well that is definitely not honored at the moment. Might require a new API to implement that, not sure.
No current nor future plans to solve this problem for ages. Closed as WONTFIX.
Jano, do you agree with this resolution? I think there are still valid problems outstanding. 1. Currently some, but not all, context menu items have mnemonics - with no apparent pattern. If this needs to be fixed, issues should be filed for appropriate modules. 2. The explorer component does not distinguish between right-click and S-F10 for invocation. If this is still a problem, it must be addressed in the explorer infrastructure, as modules have no influence over the display mode.
Re 1. It should be all or nothing. As it seems we have the infrastructure to provide mnemonics in contextual menus, we just need to define them. Ideally QEs would file issues in respective modules. See for example issues #95541 and #95539. Re 2. That's how it behaves on Windows XP. It distinguishes between mouse and keyboard invocation in contextual menu. Mnemonics add clutter and they are useless for those who want to use mouse. So we should do the distinction in NetBeans as well. Ideally such support would be in Swing.
am removing the I18N in the summary as this is not an i18n kind of issue/situation itself. ken.frank@sun.com
So is there someone from QE filing issues for #1 and #2 as Jano suggested?
Petr Chytil will look at it.
I've filled umbrella issue for the #1. See issue #118523
Problem #2 is being solved in issue #70255 - but last comment was posted two years ago...