Bug 106162

Reassigning this issue to newly created 'ruby' component.

The syntax error messages are coming from JRuby directly. I'm still not clear on how to handle those issues.

can this be fixed for nb6 ? most other areas have the tooltips for this kind of case
coming from bundle files.

ken.frank@sun.com

just changing to proper priority for messages issues; I realize since it
comes from ruby it might not be doable in any case.

ken.frank@sun.com

Right - JRuby is not localized. According to Tom Enebo, error messages have IDs, which could in the future be used for
localization on the IDE side - the IDE would display localized messages corresponding to the IDs. However, this is
probably too big a task for NetBeans 6.1, so I suggest waiving this issue for NetBeans 6.1.

Yes, the message ids were just added in JRuby 1.1 (at our request). 

Asking for a waiver for 6.1. Justification - the localization support in JRuby runtime came too late to be used in
NetBeans 6.1, will be done for the next release. The workaround is not to rely on the error messages in the editor.

Just FYI - localizing these messages is not trivial outside of JRuby. It's true that we now have an "id" associated with
each error message such that we know which message a given string corresponds to, and we could use that id to pick out
our own localized error message for that error.  But a lot of these error messages are parameterized (e.g. syntax error,
unexpected "foo"). Here "foo" is some symbol that is supposed to be included in the error message, but we only know the
id of this error message - SYNTAX_ERROR. So we'll have to go and try to pull out portions of the English message to
compute keys for the localized messages. 

So does this mean it would be desirable to do more work on the JRuby side in order to avoid this hack? 

Should this issue be waived for NetBeans 6.5?

Yes - for reasons I explained in my March entry, it -cannot- be solved properly on the NetBeans side because we're
getting assembled error messages, not message keys and parameters. Thus, it needs to fixed on the JRuby side. And yes,
we definitely can't do anything about this in 6.5.

Ok, so can we please have an issue filed against JRuby so it can be solved in a future release. 

I am requesting a waiver for NetBeans 6.5:
User impact: messages coming from JRuby parser will be shown in English only, not in the language of the IDE.
Workaround: Try to understand the English message
Justification: Can not be fixed within the NetBeans code, there is insufficient support for localizing the messages in JRuby

It is really P2 that the programmer must read the syntax errors in English? Seems to me like P5. There were not any
duplicates of this issue a and I think there will never be. I guess the reason is that developers all around the world
are quite comfortable with output of tools like javac to be in English. Similarly as they are used to use APIs like
Collections#sort in 'English'.
Taking into account effort for needing to fix this issue I'm for closing as 'will not fix'.
Don't take me wrong, I agree witch localization and/or internationalization on places like dialogs, menu, buttons, ...
but this is completely different case IMO.

> I guess the reason is that developers all around the world are quite comfortable with output of tools like javac to 
be in English

I believe we have also (at least) Chinese and Japanese JDKs, including translated tool output.

Not that I'd disagree with downgrading this to P5, but I don't think it should be up to each individual developer to 
take liberties in I18N bug priorities, rather the priority guidelines should be re-evaluated (and AFAIK there is 
already an ongoing effort to do just that).

> I believe we have also (at least) Chinese and Japanese JDKs, including
> translated tool output.

JDKs like (*very* mainstream tools), might be. Tools for other languages, likely not.

> Not that I'd disagree with downgrading this to P5

For me, still closer to reality than current priority - P2. Might be something in between.

> but I don't think it should be up to each individual developer to take
> liberties in I18N bug priorities

Sure. That was just my opinion, I did downgrade anything.

In general I think that if an underlying tool used in NetBeans does not support I18N it should not be seen as a 
*defect* in the IDE. Of course, we should prefer tools that do support I18N when there is choice, but that is not the 
case here. 

Just something to think about when re-evaluating the guidelines.

to developers, some comments

1. I think some of you might be viewing this issue the wrong way - it was filed as a normal
issue about not seeing some messages from bundle file.  Typically, when such issues 
are because the messages really come from somewhere else, whether its language like jruby
or dbase or wherever, the issue is just closed and of course we accept that.


2. In some few cases, if the messages/labels are very many and very visible to user,
dev teams have done like for this issue - left it open but waived it, since issue
mentions about a process for showing msgs from ids. 

sometimes dev have provided wrapper modules that interface with these other non nb jars
that do get the msgs from those modules - but this has been from developer evaluation and decision
of how many msgs and how visible the msgs are

3. we can't know in advance that some messages, like these, which shows at a place
where often there are messages from bundle files or from some translated parts of jdk,
is really from somewhere else - thats why issue is filed. like other issues, all you need
to do is evaluate and close.


4. from other comment
"It is really P2 that the programmer must read the syntax errors in English? Seems to me like P5."
... 
Don't take me wrong, I agree witch localization and/or internationalization on places like dialogs, menu, buttons, ...
but this is completely different case IMO."

again, in good faith we filed an issue - all you needed to do was close it since msgs are from jruby
(but I think its great that it was left open to fix for future release since dev team feels its
impt to have these msgs be translatable)

5. from other comment below 
"In general I think that if an underlying tool used in NetBeans does not support I18N it should not be seen as a 
*defect* in the IDE"

again, since we don't have esp and since we are told to file issues rather than to ask first on alias
about such things, we filed an issue where saw something in ide; your evaluation of it (as have been done by man
other evaluations) is that its from jruby, not nb, thus can't be fixed, (or in this case fixed in future)

that seems like the right thing to do but please don't blame us for not knowing in advance that msg
was not from nb. from my understanding and from experience with many such issues as this one,
thats part of the evaluation process and we accept the results of such evaluations.

ken.frank@sun.com

IMO whether this is a bug or not, and the priority, are *independent* from the cause and source of the bug. If
non-English users saw this as an important thing, then it should be a high priority defect regardless of whether the
message comes from NetBeans or JRuby. If they saw it as an unimportant little nuisance, then that too would be
independent of where it comes from. 

Based on the discussion above, and the (lack of) feedback from real users so far, I suggest to settle on leaving this
open as a P4 defect, what do you think?

Ken, nothing personal, I spoke purely about the issue problem itself from my point of view. I spoke to everyone in this
issue, not to you or the I18N team personally, just discussing the issue.

So I agree that this one is P4 since it has low impact on users, if any.

*** Issue 165666 has been marked as a duplicate of this issue. ***