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.
NOTE - this is not about translating samples; they are not translated; this is about other i18n aspects part of this is related to new project encoding property and part is related to encoding handling for generating javadoc assumption here is that it is ok for user to change some labels or other ui items part of using the sample. And it might be that the created project might have multibyte in it anyway if project name has multibyte in it and thats used as name of package or class, or that date is part of the temate and so would have mbyte characters in it. (this is legal in nb and java) 0. this is for the visualweb sample projects - the default case now for nb projects now (new implementation for nb6) is that utf-8 encoding is used but if encoding was changed in another project, that encoding becomes the global encoding value. 1. for other nb samples that had not been regenerated, when multibyte is added to some label and thus its then in the java code, when compiling the project or when generating javadoc, some warnings about encoding are shown but the project and javadoc compiles ok. 2. the fix for javadoc has been filed for various project types; the fix relates to javadoc.encoding property defined in the project.properties wasn't used only defined. 3. the regeneration of the sample projects for nb6 could help with these warning since the build-impl.xml will also be regenerated. Tomas can provide more information on these topics. 4. Also, if these samples might have jsp or html files in them and the encoding value used in creation of these files is different than in past, and works with the new project encoding, so regeneration of the samples might help those files in the samples to be compatible with that. 5. NOTE - however 108682 is not yet fixed for visualweb in general (seeding the jsp files with project encoding - this might cause separate problems for both samples and non samples; suggest this issue be fixed soon.
*** 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