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.
see 131561 also. currently, the only way to change project encoding value is to change it from within an existing project, but that means that project files created or imported at time of project creation, or up until the change happens, would be in the previous encoding, and would need to be changed by user somehow; nb does not provide such functionality though there is a uc module that does. thus the way to avoid needing to change encoding of project files now is just to - create some project that would be not used - change its encoding to what is wanted. - create a new project; it will be in that new encoding from the beginning However, if there would be an option that would allow user to change what global project encoding would be, then it means that at project creation time, that the project files would already be in that encoding; and seems easier and cleaner for user.
Are you suggesting that the global project encoding is to be used for creation of all new projects? Sounds good, however we don't have a project category in Tools/Options right now. I'm not sure global project encoding fixes the problem though. it will only help users to identify the solution in an easier way than the current workaround you described.
to answer the questions: Are you suggesting that the global project encoding is to be used for creation of all new projects? Sounds good, however we don't have a project category in Tools/Options right now. answer - yes that is the suggestion since it seems more cleaner than the current way (what I described I don't think is a workaround;its the way it needs to be done if one wanted a project without any previous files that had a different encoding and thus those previous/original files would need their encoding changed somehow once the project encoding was changed (ide does not do this nor have tools for this though there is a dev module at uc that does it, but that seems like a lot of work for user to do in this case. I'm not sure global project encoding fixes the problem though. it will only help users to identify the solution in an easier way than the current workaround you described. answer - I was not clear enough in summary or description - what I meant to say is that a user who wants a new project in an encoding other than the current global encoding value, needs to go thru the steps I mentioned. If there was an option, they would not need to go thru those steps, they would just change the option, then create a new project and it (and subsequent projects) would be in that encoding from the beginning until they changed that option again. ken.frank@sun.com
Change of default owner.
If you import files from elsewhere, simply set the project's encoding to the encoding of those files after you create it. If you want to retroactively change the encoding of a set of files already on disk (generally these would be versioned), you can use native2ascii + ascii2native to do so.