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 - regenerate sample projects for nb6 | ||
---|---|---|---|
Product: | obsolete | Reporter: | Ken Frank <kfrank> |
Component: | visualweb | Assignee: | Ch Nguyen <cnguyencasj> |
Status: | RESOLVED INVALID | ||
Severity: | blocker | CC: | potingwu, quynguyen, tzezula |
Priority: | P3 | Keywords: | I18N |
Version: | 6.x | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Ken Frank
2007-08-21 15:58:10 UTC
*** Issue 115038 has been marked as a duplicate of this issue. *** can this be done soon for nb6 ? we want to make sure behavior of all projects and samples is consistent. this is not related to translated product; this applies to en release. ken.frank@sun.com Please reassign as appropriate once you evaluate. thanks. After gathering more information from Quy, Tomas and Po-Ting, I finally understand what this bug is about. The correct behavior for creating any new sample apps would be to inherit the encoding that the sample app was set for when the sample app was created originally. Then if the user decides to add a new page, the new page will use the current global encoding which can be different from page to page. Therefore, I'm closing this as invalid. am not an expert on all this, but seems like encoding of sample app project should be that of the global encoding value, not the encoding used to orginally generate the sample app. and that if user does change encoding of sample project, that this encoding value becomes the new global encoding value, just like any other project. and that sample app is a nb6 project that takes advantage of all other feq things and javadoc fixes, etc. see these other issues on regen of sample apps 115902, 1122814, 108908, 108907, 108906, 108903, 108902 ken.frank@sun.com Just view a sample app just like a copy of an existing project. If you open an existing project, each page of that project can have different encodings. So a sample app as an exact copy of a project should preserve all the encodings that the orignal project has. Po-Ting might be able to give you more details if needed. When we change the encoding, we don't change the encoding for all the old pages already created. For the sample app, their pages were created and the original author should already assigned the 'right' encoding for each page. The New Project actions should not change the encoding at this time. Its strange that these would not need regeneration and all other projects it was felt did, as per bugs I mentioned in other comments. But if not, at least make sure that the sample projects encoding does not become the value of the global feq, since the encoding of the sample project might be different from the current global encoding unless you have the encoding of the sample project come from the global encoding value. that is the problem with one of the issues mentoined below - that its samples does impact the global encoding value itself, altho user has done nothing to indicate they want to change it. ken.frank@sun.com I can see that, at least for one of the samples I tried, its project encoding value does not change the current global project encoding value. other sample apps are opened in the current global encoding value. Also, unless its assumed that user is forbidden to change some label or data of the ssample itself,that since user might be assuming the other encoding for projects that they had set before, than utf8 that vwp examples use, there might be some problem in building of the project. ken.frank@sun.com |