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> |
| Status: | NEW --- | ||
| Severity: | blocker | CC: | jf4jbug, jpokorsky |
| Priority: | P2 | Keywords: | I18N, RELNOTE |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
|
Description
Ken Frank
2008-04-21 23:04:29 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.
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 ? ken.frank@sun.com 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? 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 ? ken.frank@sun.com 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! 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 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 ? ken.frank@sun.com 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. |