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.

Bug 16272 - I18n - Serch Results dialog "Show in Explorer" button, a Explorer does not move.
Summary: I18n - Serch Results dialog "Show in Explorer" button, a Explorer does not move.
Status: CLOSED FIXED
Alias: None
Product: utilities
Classification: Unclassified
Component: Code (show other bugs)
Version: -FFJ-
Hardware: All Solaris
: P4 blocker (vote)
Assignee: issues@utilities
URL:
Keywords: I18N
Depends on:
Blocks:
 
Reported: 2001-10-05 11:43 UTC by Hiroshi Nakatsubo
Modified: 2003-07-01 15:32 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Image1.gif (10.15 KB, image/gif)
2001-10-05 11:46 UTC, Hiroshi Nakatsubo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hiroshi Nakatsubo 2001-10-05 11:43:37 UTC
The reappearance method of a bug. 

1.Main menu -> Edit -> Find is chosen.
2.It searches in the Serch Filesystems dialog.
3.Serch Results dialog is displayed.
4.Even if it pushes a "Show in Explorer" button, a Explorer does not move.
(Image1.gif)

Build:010925_ee_ja
*OS:Solaris 8
*JDK:JDK1.3.1
*JSP_taglib
------------------------------------
hiroshi.nakatsubo@Sun.COM 2001-10-05
Comment 1 Hiroshi Nakatsubo 2001-10-05 11:46:45 UTC
Created attachment 2861 [details]
Image1.gif
Comment 2 Jan Becicka 2001-10-05 11:58:26 UTC
reassigning to core
Comment 3 Hiroshi Nakatsubo 2001-10-05 12:37:36 UTC
Build:010925_ee_ja
*OS:Solaris 8
*JDK:JDK1.3.1
*Core
------------------------------------
hiroshi.nakatsubo@Sun.COM 2001-10-05
Comment 4 Peter Zavadsky 2001-11-02 10:08:44 UTC
I think this is invalid. I guess you excpect something else it is
designed to do (what do you exactly mean the explorer should move?).

The "Show in Explorer" button just selects the node in Main Explorer
window and requests focus for it. And this works as I tried it out in
last build.

Please reopen if you think there I missed something.
Comment 5 Hiroshi Nakatsubo 2001-11-09 10:37:06 UTC
Since seemingly it is a l10n_japan bug, I investigate here. Thank you.
Comment 6 Keiichi Oono 2001-12-05 01:42:02 UTC
This problem means:
"Show in Explorer" button does not work with localized
Bundle_ja.properties. When we use Japanese version and click "Show in
Explorer", the focus is not moved.

I also changed the Priority from P4 to P2, because one of the features
does not work.

My investigation:
When I delete org/netbeans/core/Bundle_ja.properties from
lib/locale/core_ja.jar, "Show in Explorer" works fine. I'm guessing
this problem is caused by translating one of the string in
org/netbeans/core/Bundle_ja.properties. But I'm not sure which message
must not be translated. Could you fix it to work with translated
Bundle_ja.properties?
If you have any questions or suggestions, please let me know.
Comment 7 Jan Zajicek 2001-12-05 09:38:38 UTC
Passing back to Peter to evaluate again.
Comment 8 Peter Zavadsky 2001-12-05 10:24:46 UTC
This is part of utilities module, not core. Therefore it shouldn't be
affected by removing bundle from core. That's sounds really strange.

The bundle setting the label & mnemonics for the button is in
utilities module ->
utilities/src/org/netbeans/modules/search/Bundle.properties

the keys  TEXT_BUTTON_SHOW (label) and TEXT_BUTTON_SHOW_MNEM (mnemonic).
Check them out please.

Reassigning to utilities.
Comment 9 _ lkramolis 2001-12-05 11:35:26 UTC
I found, where is the problem:

org.netbeans.modules.search.LocationInfoPanel::showInExplorer
    if ("Filesystems".equals(rootContext.getName())) { // NOI18N

Name "Filesystems" IS localized. I am looking for better test, if
rootContext is Filesystems node.

Priority set back to P4, because it is not so big defect and simple
workaround exists.
Comment 10 Keiichi Oono 2001-12-05 12:19:57 UTC
Thank you for your investigation!
P4 is OK, because I've verified that workaround make "Show in
Explorer" work. The following string must not be translated until this
problem is fixed.

   org/netbeans/core/Bundle_ja.properties
   dataSystemName=Filesystems
Comment 11 _ lkramolis 2001-12-05 13:40:15 UTC
Fixed in release33 branch, so no workaround is need.

--

Index: src/org/netbeans/modules/search/LocationInfoPanel.java
===================================================================
RCS file:
/cvs/utilities/src/org/netbeans/modules/search/LocationInfoPanel.java,v
retrieving revision 1.4
diff -u -r1.4 LocationInfoPanel.java
--- src/org/netbeans/modules/search/LocationInfoPanel.java	8 Nov 2001 09:30:33 -0000	1.4
+++ src/org/netbeans/modules/search/LocationInfoPanel.java	5 Dec 2001 13:35:12 -0000
@@ -228,6 +228,7 @@
         // get all TopComponents and find main explorer panel (it's
not very nice, I know...)
         Object[] comps =
TopComponent.getRegistry().getOpened().toArray();
         boolean foundAndSelected = false;
+        Node nodeFilesystems =
TopManager.getDefault().getPlaces().nodes().repository();
 
         for (int i=0; i  < comps.length; i++) {
             if (comps[i] instanceof ExplorerPanel) {
@@ -236,7 +237,7 @@
                 Node rootContext;
                 if ((em = ep.getExplorerManager()) != null
                 && (rootContext = em.getRootContext()) != null) {
-                    if ("Filesystems".equals(rootContext.getName()))
{ // NOI18N
+                    if (nodeFilesystems.equals (rootContext)) {
                         // Now find the node in repository hierarchy...
                         // Node obtained from DataObject can't be
used because
                         // it is not in the hieararchy (there is a
FilterNode
Comment 12 Ken Frank 2001-12-05 16:37:59 UTC
2 questions -

1. Does the org/netbeans/core/Bundle_ja.properties
   dataSystemName=Filesystems
still not to be translated, with this fix ?
If so, can #NOI18N go in bundle file ?


 2. As mentioned below,             
utilities/src/org/netbeans/modules/search/Bundle.properties

                  the keys  TEXT_BUTTON_SHOW (label) and
TEXT_BUTTON_SHOW_MNEM (mnemonic).
              if the values in bundle file of these types
are N/A, does that mean they should not be translated
(I see N/A now in many bundle files in nb, related perhaps
to a11y ? as ACS_

And in same message file are some values "null". Must they
not be translated ? I realize they probably wouldnt but in testing
it we do, so need to know if it ok if these kinds of things are
translated.

ken.frank@sun.com 12.05.01
Comment 13 _ lkramolis 2001-12-05 16:47:01 UTC
2 quick answers -

1) No. It can be localized now.

2) I do not know. It is realy a11y - some a11y keywords.
Comment 14 Keiichi Oono 2001-12-20 08:33:44 UTC
Verified on 3.3.1 dev build 200112180331
Comment 15 Quality Engineering 2003-07-01 15:32:03 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.