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.
|Summary:||I18N - javadoc search should work for translated javadoc|
|Product:||java||Reporter:||Ken Frank <kfrank>|
|Component:||Javadoc||Assignee:||Jan Becicka <jbecicka>|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
Description Ken Frank 2008-04-21 23:04:29 UTC
see 133174 for more on situation about zh or other translated jdk javadoc not being recognized or used for code completion. It was mentioned in that issue that custom search needs to be written for zh or other translated javadoc languages, thus this issue is about that. Since javadoc is now translated in other languages and more might be happening (I already saw one about Portugese), then could a more general approach to search happen instead of needing custom for each langugage - that could be more general and i18n kind of approach ?replace architecture of searching to run not over html javadoc but over the java model index. Jan mentioned about "...replace architecture of searching to run not over html javadoc but over the java model index." Could this be considered for 6.5 ? And is there some workaround for now that could be done for Chinese ? There is a separate plugin module which is in progress and for 6.1 uc, that will have the jdoc for en, ja and zh in it, so fix for 133174 seems needed but also workaround for this issue for zh would be helpful.
Comment 1 Tomas Zezula 2008-04-22 07:47:37 UTC
Wrong category. As Honza pointed out in the issue 133174 the SearchEngine is language dependent. >"...replace architecture of searching to run not over html javadoc but over the java model index." is not solution, will not work for javadoc with no binary, will not work for partially build javadoc like JDK, will not work for javadoc build from IDLs as OpenOffice modules do and so on. Resolved as WANTFIX.
Comment 2 Ken Frank 2008-04-22 15:54:47 UTC
But since zh javadoc will be officially released to users, it means that they won't be able to have it searched, thus it seems like this would be still an issue/task rather than just an enhancement ? Rebecca, can you clarify more about if the zh javadoc and perhaps other translations are official sun release or release as part of the open jdk projects ? firstname.lastname@example.org
Comment 3 Rebecca Liu 2008-04-23 09:34:52 UTC
I agree with Ken. This is an important function for developers. zh_CN and ja Javadoc API are official releases. Brazilian community are also translating a lot of API docs. So does Spanish community. I heard zh_TW also has such plan. But at least we hope the zh_CN Javadoc Index Search could work. I also see the queries from Chinese users. I guess such a file is needed: http://hg.netbeans.org/jet-main/file/64ae3a0f691c/javadoc/src/org/netbeans/modules/javadoc/search/SearchThreadJdk12_japan.java . Please tell us how we could make one for zh_CN?
Comment 4 Ken Frank 2008-04-23 16:26:19 UTC
I thought that those custom translations were needed only for earlier 1.2 jdk javadoc and those localized msgs are not in bundle files anymore ? email@example.com
Comment 5 Rebecca Liu 2008-04-24 06:42:51 UTC
There are two files for Japanese Javadoc search function: http://hg.netbeans.org/jet-main/file/64ae3a0f691c/javadoc/src/org/netbeans/modules/javadoc/search/Jdk12SearchType_japan.java http://hg.netbeans.org/jet-main/file/64ae3a0f691c/javadoc/src/org/netbeans/modules/javadoc/search/SearchThreadJdk12_japan.java I wonder if every time when we add a language, we need to create such two files? Could the owner of this module help to clarify it? Many thanks!
Comment 6 Jan Pokorsky 2008-04-24 17:00:30 UTC
kfrank: Since we have not supported searching in other javadoc translations than English and Japanese yet it can hardly be a defect. First, it has to be implemented by someone. kfrank: custom engines are still necessary as the search tool needs to determine if the result is class, interface, ... and these keywords are usually translated in html files. It has nothing to do with bundle files. rebeccaliu: Yes, you need to implement the same classes for each language as for Japanese. The main problem is that html is a presentation format. So other than text search is an issue. In order to avoid search engine per language we would have to change the source where we search. So I see following possibilities: 1. reuse java symbol index to find queried java elements and then map the result to URLs + quick, reliable - index is not implemented yet (scheduled for NB 6.5 or later) - does not work for attached javadocs without binaries as Tomas mentioned 2. use the present default (English) engine and for other languages map URLs to java elements if they exist to resolve element kind + doable in scope of NB 6.5 +- will partially work for attached javadocs without binaries. Queried text will be found but not resolved (class, interface, ...) - performance - still depends on presentation format (html) that can change for different jdk versions and languages
Comment 7 Ken Frank 2008-04-24 18:24:31 UTC
Jan, thanks for clarifying about it. somewhere or somehow I'd gotten impression, perhaps from filenames that referred to Jdk12, that the custom search was needed just for older jdk, and also I'd seen some msgs removed from a bundle file that had ja translations even in en bundle file, so thought again they were removed since it was just about older jdk. now its clear. am wondering if, since reality is that zh javadoc exists and will be part of a uc module that has the en and zh/ja jdocs as part of it, if we should relnote about the find and/or add to wiki faq that the find wont work now for zh jdoc and workaround is to use it from browser ? firstname.lastname@example.org
Comment 8 Rebecca Liu 2008-04-25 03:50:10 UTC
Thanks for the information, Jan. Now it is pretty clear to me. It seems that solution 2 will work for either added zip or nbm. Please let me know if you need any help regarding to adding Simplified Chinese specific search engine in 6.5. We would like to help implementing this feature in next release.