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.