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 - use translatedfiles to prepare translated info.xml files during ml nbms build | ||
---|---|---|---|
Product: | www | Reporter: | Ken Frank <kfrank> |
Component: | Builds & Repositories | Assignee: | rbalada <rbalada> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jrechtacek, keiichio, krajeswaran, masaki, wzhang |
Priority: | P2 | Keywords: | I18N |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 118390 |
Description
Ken Frank
2007-03-25 17:10:27 UTC
Please allow me add a comment. I'm always delivering translated info.xml for UC releases, but I'm not doing the translation. Because all the strings in that xml are contained message resource files Bundle.properties. What I always do is: 1. Pick up appropriate strings from Bundle_ja.properties or Bundle_$locale.properties for other locales 2. replace English string with the above string 3. license information is English in recent releases I don't think we have to use CVS and l10n-kit for info.xml localization. English info.xml is always generated from MakeNBM ant task in the build script, so I would like to request to generate localized info.xml (e.g. info_ja.xml, info_zh_CN.xml) from MakeNBM ant task as same as English xml. Please see another issue for the autoupdate: http://www.netbeans.org/issues/show_bug.cgi?id=58118 Since autoupdate has been fixed to support localized info.xml, I guess the following tasks can be automated: - Generate localized info.xml - re-package NBMs with the localized info.xml Would you give your any thoughts? I filed this based on feedback over the years from various members of translation team as well as recent feedback from your project management. Can I ask that translation team discuss among yourselves to see if its still something that is wanted (info,xml in kits and related processes) - its not about anything else. Please let me know in some separate mails since base team should not spend time doing this if its not important to have; it was communicated to me in past that it was important to have, ken.frank@sun.com As per keiichio, all the information that is required for building an info.xmml are already part of the workspace and also part of l10n kit. Therefore, the repository/kit issue, which used to exist, seems to have been resolved by itself over time. There are still two issues that need to be addressed: - Even though all the individual pieces of data are available, localized info.xml files themlseves are still not prepared by the build script. This forces the l10n teams to prepare them manually and to store the generated info.xml files on their servers for later reference. As keiichio has mentioned, this problem can be solved if MakeNBM is modified to produce localized info.xml automatically. - Once the localized info.xml files are present, the question is how should the nbms be produced? 1. A single nbm can be produced with all the info.xml files. Since au client now supports multiple info.xml files in a single nbm, this should work. 2. Prepare a separate nbm for each locale with code+lang_bundles+lang_info_xml. 3. Prepare a separate nbm for each locale but only with lang_bundles+lang_info_xml. Then we can use the process outlined in http://platform.netbeans.org/articles/how-to-do-localization.html. I think we should file a separate RFE to discuss both the above issues. Pl. inform if you agree and i will file a new RFE. I don't recall seeing info.xml in l10n kits and I don't recall seeing them in l10n.lists and thus localized nbms wont be built from using the info.xml translated files put back into translatedfiles -- and all that is the context of this issue. I realize that getting the info.xml into the cvs and into the lists is activitiy of developers but this issue is about initiating that activity to happen, not from filing separate issues on each module but a unified approach with dev team leadership. Can we keep discussion of the above items to this issue as filed ? For the other things mentioned, I do suggest filing a separate issue(s) ken.frank@sun.com There is alternate idea. First of all I have to say that the info.xml file is *generated file* and thus is not supposed to be part of L10Nkit. Don't get sad, there's a solution. It's generated from some properties file. It's very likely that such a "Localizing-Bundle" is regular part of L10Nkit and thus translated and available somewhere in translatedfiles/src. I've also heard there's possibility to have Info/info_${locale}.xml inside of NBM file. So the alternate idea is to utilize the information described above and generate ML NBMs with multiple translated info.xml files by default. Moving to RE queue for further re-assignments. Changing from DEFECT to ENHANCEMENT. Targeting to Milestone 11 for now. As an alternative to producing ML nbms with multiple jars and info.xml files, have you considered building individual ML nbms each targeting a language, as described in http://platform.netbeans.org/articles/how-to-do-localization.html ? Reassigning to me. Checking in nbbuild/antsrc/org/netbeans/nbbuild/MakeNBM.java; /cvs/nbbuild/antsrc/org/netbeans/nbbuild/MakeNBM.java,v <-- MakeNBM.java new revision: 1.78; previous revision: 1.77 done <makenbm> is used in the external build harness. Will this patch have any effect on existing build scripts? It is too large for me to follow what it is doing. Jesse, it should be safe for external build harnesses. I'm sorry if following description is cryptic, feel free to ask for further explanation. The change has added support to allow <makenbm locales="${locales}"/> attribute and the task now reads OpenIDE-Module-Localizing-Bundle manifest value and tries to locate localized versions of that bundle in localized module jarfile(s). For example you can have module jarfile "modules/org-foo-bar.jar" with localizing Bundle "org/foo/bar/Bundle.properties" and some localized jarfiles in "modules/locale/org-foo-bar_${locale}.jar", which contain "org/foo/bar/Bundle_${locale}.properties" files (each localized jarfile can have one localized localizing bundle file. These localized jarfiles are checked for existence of such localized localizing bundle and if found, their values are used for creation of localized info.xml file in Info/locale/info_${locale}.xml file. These localized info.xml files are then added to NBM. |