Bug 26705 - I18N - Find tool does not search localized properties files
I18N - Find tool does not search localized properties files
Status: VERIFIED FIXED
Product: utilities
Classification: Unclassified
Component: Search
3.x
All All
: P1 with 6 votes (vote)
: 6.x
Assigned To: issues@utilities
issues@utilities
: ARCH, I18N
: 35717 139844 150497 157863 164561 (view as bug list)
Depends on: 48263
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-22 09:51 UTC by smartgonzo
Modified: 2010-09-06 06:41 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description smartgonzo 2002-08-22 09:51:52 UTC
If you create a property file other than the default one 
(for an other language), the find tool in the explorer 
does not find anything anymore. If you try to find a word 
or for some cvs modified file, you get an empty result 
list.

I try this with a default properties file saved in cvs and 
the new one just created and saved in the csv file system.
Comment 1 hiroshiy 2002-10-25 11:25:06 UTC
I investigate this issue, right now.

For any multibyte characters in Properties file
must be encoded in "unicode".
But, when I input japanese characters
to properties file in "EUC-JP" encoding,
japanese entries are detected from "Find".

I think that, encoding function around "Find"
seems to be wrong.
Comment 2 Jesse Glick 2002-12-23 16:34:56 UTC
Consistent use of the I18N keyword.
Comment 3 Marian Petras 2003-01-29 11:31:37 UTC
The problem is that localized .properties files are not searched at
all (if the defualt properties file exists).
Comment 4 Marian Petras 2003-03-03 13:07:53 UTC
The problem is that the search mechanism works with the assumption
that only the primary file of each DataObject need to be searched. All
variants of a properties file (for various locale) comprise a single
DataObject. The DataObject's primary file is the properties file for
the default locale. Files containing localized strings are the
DataObject's secondary files and thus are not searched.
Comment 5 Marian Petras 2003-03-28 09:09:13 UTC
After the primary cause of this bug is solved (searching only the
primary file), searching English strings should work.

But if a user tries to find - for example - a Japanese symbol, it
won't be find either, since all Japanese symbols are translated to
form \uxxxx where 'xxxx' are four hexadecimal digits, in .properties
files. So the searching mechanism will have to apply some special
filter when searching .properties files.
Comment 6 Marian Petras 2003-08-22 10:38:10 UTC
*** Issue 35717 has been marked as a duplicate of this issue. ***
Comment 7 Marian Petras 2003-10-06 15:55:17 UTC
The problem of not searching characters saved in form '\uxxxx' is now
tracked as issue #35159 - "Allow searching non-English properties files".
Comment 8 Ken Frank 2003-10-06 16:15:15 UTC
added i18n word to synopsis, this helps for i18n bug tracking
ken.frank@sun.com
10/06/2003
Comment 9 Tomas Pavek 2008-08-15 12:56:50 UTC
*** Issue 139844 has been marked as a duplicate of this issue. ***
Comment 10 Marian Petras 2008-10-17 14:56:17 UTC
*** Issue 150497 has been marked as a duplicate of this issue. ***
Comment 11 rcasha 2008-10-17 15:34:14 UTC
Is there any intention of fixing this bug? It's been around since 2002.
Comment 12 Marian Petras 2008-10-17 16:36:00 UTC
It will not be fixed in NB 6.5 (to be released soon).

Regarding the near future (NB 7.0):
It depends on resources (time). If I will continue maintaining this module (together with other four modules), I cannot
promise I will have time for this. If someone else takes over the maintenance, the chance is quite high that they would
fix issue #48263, which would also fix this bug. But nothing has been decided yet.
Comment 13 Andrey Yamkovoy 2009-02-02 11:27:17 UTC
Since issue #48263 was fixed this issue is fixed too.
Verified on the trunk build, search is looking into all localized properties files.
Comment 14 Michel Graciano 2009-02-04 11:48:58 UTC
*** Issue 157863 has been marked as a duplicate of this issue. ***
Comment 15 Michel Graciano 2009-02-04 11:49:48 UTC
v. 200902011401
Comment 16 Michel Graciano 2009-02-04 11:53:30 UTC
I changed to P1 since there is no workaround for this issue, afaik. I hope to see it for 6.5 patch 3 too.
Comment 17 Tomas Pavek 2009-02-04 16:41:15 UTC
It's up to the module owner (and QE) to decide, but my feeling is the change was fairly big, affecting other things, 
so a bit risky for a patch (backport).
Comment 18 Andrey Yamkovoy 2009-02-04 16:52:52 UTC
I agree. This fix is too risky for the patch. 
Comment 19 Andrey Yamkovoy 2009-05-12 10:14:08 UTC
*** Issue 164561 has been marked as a duplicate of this issue. ***
Comment 20 roti 2010-09-03 14:41:34 UTC
It is still broken in 6.9.
When I have a localozed properties file, searching through the project, does not match the localized string in the properties file.
Comment 21 Alexei Mokeev 2010-09-06 06:40:18 UTC
This issues has been fixed for 6.7 and verified.

If some search for localized strings doesn't work for you in 6.9, then please file the new bug with detailed steps to reproduce. A sample project is also appreciated.
Comment 22 Alexei Mokeev 2010-09-06 06:41:47 UTC
Restoring verified state, as was set on 2009-02-04


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