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
I try this with a default properties file saved in cvs and
the new one just created and saved in the csv file system.
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.
Consistent use of the I18N keyword.
The problem is that localized .properties files are not searched at
all (if the defualt properties file exists).
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.
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.
*** Issue 35717 has been marked as a duplicate of this issue. ***
The problem of not searching characters saved in form '\uxxxx' is now
tracked as issue #35159 - "Allow searching non-English properties files".
added i18n word to synopsis, this helps for i18n bug tracking
*** Issue 139844 has been marked as a duplicate of this issue. ***
*** Issue 150497 has been marked as a duplicate of this issue. ***
Is there any intention of fixing this bug? It's been around since 2002.
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.
Since issue #48263 was fixed this issue is fixed too.
Verified on the trunk build, search is looking into all localized properties files.
*** Issue 157863 has been marked as a duplicate of this issue. ***
I changed to P1 since there is no workaround for this issue, afaik. I hope to see it for 6.5 patch 3 too.
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).
I agree. This fix is too risky for the patch.
*** Issue 164561 has been marked as a duplicate of this issue. ***
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.
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.
Restoring verified state, as was set on 2009-02-04