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.
I realize this is not completely an RE activity and want to get your feedback on how/where to communicate about the other parts. This is based on long time request from l10n team. - they need to translate info.xml for uc modules; not sure if they need to do it for all modules - but info.xml is not in l10n kits so they need to get, in the large nbms file, the info.xml of each module they need to translate for then they need to send by mail to RE the translated file REQUEST: 1. have the info.xml in nb cvs so it can be added to l10n.list of each applicable module (or l10n.list.uc) so then it will be in the regular or uc l10n kit. 2. they will putback the info.xml to translatedfiles/src - so that RE can use that info.xml in the building of the ml nbms. QUESTION for #1, is it technically possible for the info.xml to go to nb cvs ? if so, then I think that dev needs to add it to l10n.list or l10n.list.uc BTW, where do the info.xml files live ? is it in a cvs, or are they dynamically created from a template when a given nbm is built ? ALTERNATE IDEA ? there is one large nbm file in the builds - if one had a list of the names of each nbm that needed to have info.xml localized, a script could extract the info.xml for each and to a directory. But there would be a namespace collision since all info.xml are in Info/info.xml. But perhaps the directory name could be the basename of each nbm, so that each info.xml would go in a unique location. then these files could be provided as a special kit, and then putback to translatedfiles in the same structure, and used for building the ml nbms ?
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.