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 - Bundle-JSF.properties needs to be in l10n kits | ||
---|---|---|---|
Product: | obsolete | Reporter: | bugbridge <bugbridge> |
Component: | visualweb | Assignee: | Ch Nguyen <cnguyencasj> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | kaa, kfrank |
Priority: | P2 | Keywords: | I18N |
Version: | 5.x | ||
Hardware: | Sun | ||
OS: | Solaris | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 105741 | ||
Bug Blocks: |
Description
bugbridge
2007-02-06 15:53:17 UTC
now that vwp is in opensource and we are aligning with other modules, this is being raised back to p2; it does need to be fixed for nb6 timeframe. Having l10n manually extract was only meant as short term workaround; l10n team are our customers of l10n kits and we need to make sure like for all other modules and components, that things are in kits. ken.frank@sun.com Definitely not for M9. I also need to know how the l10nkit is build in the NB structure. Do you have any pointer? nb-re is handling this for nb6, as to how kits are/will be built. ken.frank@sun.com For any module requiring generated stuff to be in L10N kit use "antcall custom-target" syntax in local l10n.list override. Sample local l10n.list override can be found at http://www.netbeans.org/source/browse/visualweb/webui/designtime/l10n.list?view=markup Documentation about syntax and use-cases for local l10n.list override can be found on wiki page http://wiki.netbeans.org/wiki/view/NetBeans6.0L10NListHOWTO From Build Engineering point of view we reached the point where Development team takes over responsibility for L10N kit accuracy. There's infrastructure and documentation how configure your module for L10N kit build to make it accurate. Do not hesitate to file an issue against nbbuild module in case something does not work for you. Rudolf. I see some Bundle-JSF.properties in the new test, l10n kits inside the visualweb.tar Chau, see deadlock.netbeans.org/hudson/job/l10nkit A quick look at Bundle-JSF.propeties in product vs kit showed most were in kit (though i don't know if path was correct or if the files in the kit match the ones in the product) and one file was not in kit - but as Rudolf mentions, thats up to dev team to make sure the additional l10n.list files are created, populated and that the kits are accurate. I'm emphasizing this because adding the Bundle-JSF.propeties to the kit is a special and new step, and sugggest dev team make sure the files in the kit do match the files in the product of that date. Or it might be that some global pattern that could be in RE global l10n.list needs to be added to that file if its a common pattern vs needing to be in specific module l10n.list. ken.frank@sun.com Ken, which one that is not in the kit? *** Issue 109380 has been marked as a duplicate of this issue. *** Fix the generate target in xhtml so that it'll include the Bundle-JSF.properties file in the l10n-kit now. Checking in build.xml; /cvs/visualweb/xhtml/build.xml,v <-- build.xml new revision: 1.4; previous revision: 1.3 done Checking in l10n.list; /cvs/visualweb/xhtml/l10n.list,v <-- l10n.list new revision: 1.2; previous revision: 1.1 done Moving on to the next module visualweb/dataprovider/designtime. The 'generate' ant target works fine in this module. However when setting up the l10n.list to do: ant generate read global It doesn't work. I also found that the l10n-kit's visualweb.tar can't be extracted. I got "directory checksum error". This is happening in my local build as well as the download l10n-kit from deadlock.netbeans.org/hudson/job/l10nkit. So I've a new bug on that issue 111180. As pointed out in issue 111180, I was not using the gnu tar command to extract the content of the l10n-kit for verification. After I was able to extract successfully, it looks to me that all the needed Bundle-JSF.properties are now in the kit. verified. |