Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 35159 - I18N - Allow searching non-English properties files
I18N - Allow searching non-English properties files
Product: utilities
Classification: Unclassified
Component: Search
All All
: P2 with 1 vote (vote)
: 6.x
Assigned To: Marian Petras
: I18N
Depends on:
  Show dependency treegraph
Reported: 2003-07-28 08:08 UTC by fun
Modified: 2007-06-20 18:32 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description fun 2003-07-28 08:08:07 UTC
1)Open a property file that contains localized
characters in the property editor.
2)Right-click the upper folder that holds the
property file and select [Find...] from the menu.
3)Use [Substring searching] to find a localized
value which exists in the property file.
4)Find No matches.
5)This happens in ja&zh_CN locale.
Comment 1 Keiichi Oono 2003-07-28 08:27:34 UTC
Make sure to add "I18N" keyword when you report i18n bug.
Comment 2 Keiichi Oono 2003-07-28 08:46:08 UTC
I think this is a problem in search module. So I've changed category
to utilities.

The current search module is look for the string only in default
properties file (e.g. When I want to search keyword
in not default locale properties file (e.g.,
nothing can be found.

Even when I enter multibyte characters in default properties file
(e.g., multibyte characters can not be found because
they are save as unicode escape "\uXXXX".
Comment 3 Marian Petras 2003-10-06 15:50:15 UTC
Keiichi Oono evaluated it correctly - there are exactly the two
problems he/she described.

The first problem (searching only properties file for the default
locale) is a bug, indeed, and should definitely be fixed. It is
already tracked as a bug #26705 - "Find tool does not work with
localized properties files".

As regards the second problem: It is not a requirement for the Search
submodule to apply filters to certain types of objects/files.
Nevertheless, it is necessary for proper searching of non-English
properties files.

So I change this issue's type from DEFECT to a high priority FEATURE
(the other way would be to close this defect as invalid and create a
new feature request record in IssueZilla for this issue).
Comment 4 Ken Frank 2003-10-06 15:58:43 UTC
added i18n to synopsis - this helps in our i18n issue tracking -
I realize it has i18n keyword but having in synopsis is more
helpful now
Comment 5 Marian Petras 2007-04-18 16:30:57 UTC
Implementation and use of the specific encoding for .properties files (issue
#97861) resolved also this issue. Note that issue 26705 ("Find tool does not
search localized properties files") is still pending.

Modified files:
   ide/golden/deps.txt   (1.543)
   properties/   (1.69)
   properties/nbproject/project.xml   (1.12)
                                (1.1 - new)
                                (1.1 - new)

Comment 6 Ken Frank 2007-05-29 18:25:43 UTC
verified using nb6 - the actual multibyte is found.

however, searching for the escapped acscii in the actual property text file
is not found by find.

is it expected that the escapped ascii characters should be found by a full text
search ?
Comment 7 Marian Petras 2007-06-20 18:32:11 UTC
I do not fully understand your question. I assume that the user does not see any escaped characters until they enter
them themselves. Even if the user enters an escaped character to a .properties file, the next time the file is opened,
it is displayed as a real character, not in form \uxxxx. Even if the user enters a character in the \uxxxx form, the
Find feature will read it as a real character (i.e. not as the \uxxxx sequence) and the user should enter an actual
character to the Find dialog.

If the user is not able to enter the actual character to the Find dialogue and prefers specifying the character by the
corresponding Unicode value, it is possible, but only when searching with the Regular Expression check-box selected,
i.e. if the text to be found is expressed with a regular expression. The \uxxxx syntax works in this case (as specified

If you think that the user should be allowed to specify characters in the \uxxxx form (even with the Regular Expression
check-box unchecked), please file a separate issue.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo