Bug 109984 - I18N - issue for source encoding setting
I18N - issue for source encoding setting
Status: RESOLVED WONTFIX
Product: java
Classification: Unclassified
Component: Project
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Tomas Zezula
issues@java
: I18N
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-17 11:58 UTC by Masaki Katakai
Modified: 2007-07-19 12:20 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Proposal for encoding note in project properties dialog (23.05 KB, image/png)
2007-07-18 09:16 UTC, jrojcek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Masaki Katakai 2007-07-17 11:58:07 UTC
bug from bug 99344.

NetBeans M10

The default encoding should be defined in global setting e.g.
on option dialog, it should not be changed whenever user
change the setting on *particular* project. The setting is for
particular project, not for global setting. In general, settings for
particular project should not affect other projects.

I (also most users) don't understand why such global setting
will be changed (unintentionally) when I change it on property
dialog of the particular project.

I'm confused about the current behavior. When I tried to
open 5.5.1 project, which was written in SJIS encoding (Windows).
After opening the project, I changed the encoding to SJIS.
When I created a next project, I expected UTF-8 encoding because
I have changed the setting on other project. But it was set to SJIS.

Could you evaluate these things?

1. Please provide such setting on option dialog
     the default value should be defined in global setting

2. The setting of particular project should not affect others
     the change of encoding setting on project's property dialog
     should affect only the project
Comment 1 Milos Kleint 2007-07-17 12:28:42 UTC
Tome, you've done the EncodingQuery and implementation in ant java projects, right?
Comment 2 Tomas Zezula 2007-07-17 13:32:20 UTC
The issue has two parts, one is as designed and the second is already fixed.
The first problem:
Changing project encoding does not affect other existing projects, it affects the encoding in which the next project is
created. This comes form the most used use case: developer creates all (or most of project) in the single encoding. So
when the IDE is installed it creates project in UTF-8 (this is what we recommend) but the user can change this encoding
to other (ISO-8859-2), next time (s)he creates a new project it already uses the ISO-8859-2 encoding. I am afraid that
adding a new option for setting a default encoding will introduce a new UI somewhere in the advanced options which no
one will find anyway.

The second problem (probably the root problem): Project created in the NB 5.x used the default encoding, this was
already changed, unfortunately after M10. The old project now uses fall back encoding which is the OS native encoding.
Comment 3 Masaki Katakai 2007-07-17 13:55:53 UTC
> it affects the encoding in which the next project is
> created.

That's problem because the option setting UI is located on
project property dialog, not on global option dialog.

Users can not understand it will affect next created project setting.
If it will affect others, the setting UI should be provided on global
setting panel too. Only project specific settings are usually
located on project property dialog. I think many users will confused
by the UI.
Comment 4 Tomas Zezula 2007-07-17 14:30:38 UTC
I still think that it's better not to introduce the new UI and let the IDE to do this change automatically. For most of
the users it will work out of the box and they will not need to change anything (they either do projects in UTF-8 or in
other single encoding). If we introduce new UI they will probably not find it since it will be somewhere in the advanced
options. Such a user will need to change the encoding everytime (s)he creates a project.
But Jano (jrojcek) should decide this, he is an UI expert.
Comment 5 Ken Frank 2007-07-17 14:44:27 UTC
lets keep in mind also that the new project encoding handling is meant for all projects that have
implemented it, not just java project.  it was based on requests from external users for a long time.
and most project types of nb have implemented it. 

and its not just projects that have had this implemented but also related to files and then also
how other operations handle determining encoding based on the project and file encoding.

Since we are past feature freeze there is concern that changing this now could cause problems
in that another set of code changes would be needed, specs would need to be rewritten,
testing would need to be restarted, etc.

Masaki, I can tell you more of the spec on this soon.

of course your comments are appreciated; I just wanted to give a persective here in these comments.

ken.frank@sun.com
Comment 6 Masaki Katakai 2007-07-17 15:45:20 UTC
Thank you tzezula, I understand your concern but

 > options. Such a user will need to change the encoding everytime (s)he creates a project.

I think these two scenarios (setting it on advanced option or
on project property dialog each time) are not so painful tasks
for users.

 > But Jano (jrojcek) should decide this, he is an UI expert.

Yes, I agree.
Comment 7 Masaki Katakai 2007-07-17 16:26:02 UTC
 > lets keep in mind also that the new project encoding handling is meant for all projects that have

I know. Was there any wrong points in my bug report?

 > Since we are past feature freeze there is concern that changing this now could cause problems
 > in that another set of code changes would be needed, specs would need to be rewritten,
 > testing would need to be restarted, etc.

We know it will be painful to change such spec in future releases 
once it's implemented, documented and released. We now understand
the current behavior will confuse users. So I think it's time to review
the inconsistent UI and its behavior, and fix it.

 > Masaki, I can tell you more of the spec on this soon.

Thank you. Any draft available? I'd like to review asap.
Comment 8 Tomas Zezula 2007-07-17 16:39:32 UTC
>We now understand the current behavior will confuse users. So I think it's time to review
>the inconsistent UI and its behavior, and fix it.
This is what we don't know, I personally think that the current behavior is much less confusing than the proposed one.
As I explained above it fits to all common cases.
Comment 9 Tomas Zezula 2007-07-17 16:43:29 UTC
If we decide to change it we should do it as soon as possible because of the documentation and testing.
Comment 10 Jesse Glick 2007-07-17 16:54:01 UTC
I also think the current behavior is best. The IDE makes a reasonable guess as to which encoding you want for a new
project; if it's wrong you can easily correct it and the IDE will remember that; you do not need to search through the
Options dialog for a global setting (which many users might not even realize exists).
Comment 11 Masaki Katakai 2007-07-17 17:07:52 UTC
Thanks jglick,

But the problem is, the setting UI is provided on project property dialog now.
Most users will think it's a setting for just current project, not for next
created project. That's problem. Why the only encoding setting is affecting
others? There is no such setting on project property dialog in 5.x.

Will you confirm to Jano? HIE? Is it OK from the HIE point of view?

Btw, Eclipse is providing two settings - global and project.
The default value can be configured on global setting, project setting
can overwrite the default value. Project setting will not affect others.
Comment 12 Jesse Glick 2007-07-17 17:29:16 UTC
The encoding is only for the selected project. It is used as a default initial value only, for the next project:
whatever encoding you have last configured somewhere is used as an initial value since that is as good a guess as any.
If it's wrong, just change it. If you had to go to the Options dialog to change the initial value for new projects you
would in all cases be doing at least as much work as you do now, sometimes more, even if you knew this setting existed
and where it was. Our general preference is to avoid having global options when they are not really necessary.

By way of analogy: You are very lazy and like cookies. You keep a jar of cookies in the kitchen. While you are sitting
in the living room reading, you get up to get a cookie from the kitchen. An hour later, you want another cookie, so you
go into the kitchen again. The third time, you get annoyed, so you ask your friend to bring the cookie jar into the
living room. You have one cookie. Later you move to the porch, and after a while you want a cookie. You go into the
living room to get it. After a few times, you get annoyed and ask your friend to move the jar to the porch. Does this
make sense? Of course not - it would be simpler to just bring the cookie jar with you whenever you get a cookie from
somewhere else. That way, most of the time you would not have to get up just to get a cookie, but you do not have to do
anything special to move the jar either, since you were up anyway.

The risk is that even though usage is easier the way it is and the GUI is simpler, users expecting a global setting
(e.g. because they are accustomed to Eclipse) will be persistently confused and irritated by the fact that there isn't one.

There is of course no such GUI in 5.5 since file encoding was not really supported before 6.0.
Comment 13 Masaki Katakai 2007-07-18 02:20:00 UTC
Hi jglick, Thanks for explaining. Yes, I understand your point.

 > and where it was. Our general preference is to avoid having global options when they are not really necessary.

The problem is that few people are understanding the current behavior,
Nobody can imagine it will affect at next time when they create a new project
because
   - the setting UI on project property dialog
   - there is no information around the setting
How do we tell this to users? How do we explain the encoding setting is
completely different from other settings? If we continue using this,
I want to ask you to consider these things,

- describe the behavior on OLH
   I understand it will be done.
   but it would not be enough because many users do not read OLH carefully :(

- How about putting some hints near the UI?
      "Encoding : UTF-8 (This setting will be the default when you create next project)"

- or How about showing some useful message on status area of
   dialog when user select another encoding on the UI?
Comment 14 Jesse Glick 2007-07-18 02:38:32 UTC
All possibilities, but best left to Jano to comment.
Comment 15 Ken Frank 2007-07-18 03:20:20 UTC
Masaki, yes there will be documentation, faq etc on this; it is a new feature, and its always been part of the plan to
tell users
about these new features and details, and that does include olh also. 

please remember that these features have been and are still in implementation phase and not all are done yet; and there are
other details and things related to this than just project encoding.   Please have a little patience.  IMO the nb developers
have done a very good job of meeting the requirements of this, based on the voc and votes of community members.

I know your suggestions will be evaluated also as to showing info about this to users in the ui.

ken.frank@sun.com
Comment 16 jrojcek 2007-07-18 09:15:53 UTC
For users who always use one encoding, the current behavior should be okay. A global setting would not help them as they need to change it 
exactly once. We just need to explain to users that the change in project properties would affect projects created afterwards, because I agree with 
masaki that it's a bit inconsistent with behavior of other project properties and therefor potentially confusing. I like that best  using a note in the 
properties dialog saying something like:

"The selected encoding will be used also for new projects."

The note should show up next to the encoding combo box when the user changes the encoding. See the attached screenshot.

For users who use different encodings in different projects, the current behavior is inefficient, because they have to always go and check the 
properties dialog as they probably don't remember what was the last change they did for encoding. A global setting would not help them either, as 
it's just a different place they need to go. Furthermore, they would have to think whether changing the setting at project level is enough for now, or 
they should rather go to the global place because they would use the same setting for a few new projects. If we want to really fix it for those users, 
we would need to add the encoding option into the New Project wizard. We probably don't want to do it for 6.0 if at all.

Comment 17 jrojcek 2007-07-18 09:16:42 UTC
Created attachment 45286 [details]
Proposal for encoding note in project properties dialog
Comment 18 Jesse Glick 2007-07-18 19:50:49 UTC
I doubt that enough users care about setting the project encoding to merit its being placed directly in the New Project
wizard. What proportion of our users really include non-ASCII characters in their source code? (*.txt, *.java, but not
*.xml or *.properties which ignore project encoding.) I am guessing it is not very large. Consider that there are much
more widely used project properties which should have priority in going into NPW: Java source level, compiler flags,
etc. Currently we don't bother putting these into NPW (and cluttering it with extra controls) because we expect that the
defaults are good enough for a lot of cases, and it is quick enough to change the settings after the project has been
created.
Comment 19 Tomas Zezula 2007-07-19 09:38:41 UTC
Maybe there should be some advanced part of the New Project Wizard containing the encoding. Button "Advanced" causing
appearing of the advanced options in the Wizard.

Comment 20 jrojcek 2007-07-19 10:46:41 UTC
I'm fine with *not* adding the encoding setting into the NPW.

How about adding the note into project properties? Is it okay from your point of view?
Comment 21 Tomas Zezula 2007-07-19 12:20:34 UTC
Yes, I will do it.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo