> >(This might also be the solution for issuezilla
> >As same as Java source files, it is better to
have locale information in
> >mounted filesystem (e.g. local directory, cvs
filesystem). If we have,
> >we can convert locale specific character from
server's locale to
> >client's locale.
> > CVS pserver (euc-jp)
> > We can convert cvs server information from
> > we can know which locale is used in
> > local directory made with PCK encoding
> > netBeans (euc-jp)
> > we can convert directory information
(filenames or others) from
> > PCK to display multibyte correctly.
Target milestone was changed from '3.4' to TBD.
I believe Radek and filesystems will be involved in this?
Changing to defect after consulation with nb QA and comments from nb
strategy that some i18n rfes could actually be viewed as defects.
Let me know if more details are needed.
How is this a defect?
As to how this could be viewed as a defect, its as
said in comments below, that on review of some proposed
i18n rfes by nb startegy, it was stated that they seemed more like
I really don't have any more information than that..
I don`t understand what is your intention. Enhance FileSystem API to
support local information and codepages of documents provided by
FileSystem ? I don`t like this idea at all. Moreover this request
should be really considered as enhancement. I think, that NbStrategy
decisions can`t be generalized for all use cases, but perhaps I don`t
understand you well, so I would welcome to get more info about your
intention, but above all the principle how to get information about
coding, which is not trivial. So, let me know, what you exactly request.
Not sure if this issue can be more considered as valid, there are no
new comments to have more info. So, marked as WONTFIX at the moment.
If you would like to see this issue fixed, then please provide more info.
It was an enhancement request to open a file which includes characters
encoded by different encoding. We can set Encoding property for Java
and JSP files, but we can not set Encoding for html, text, and others.
If we can set Encoding property to filesystem, we don't have to set
Encoding to each files.
We have some similar requests especially to open encoded HTML file:
19928, 27240, 25191, 18607, 18651.
Would you give me your any thoughts to support Encoding for various
Thanks for info, so I reopen this issue and mark as enhancement. But
this issue can`t be solved isolated. IMHO this and other mentioned
issues must be solved together according to specification. Such spec.
must precede any next effort.
There are some plans to provide per-project encoding info. There are
no mounted filesystems any more.