Bug 21930 - I18N - encoding detection limited for output window and other areas
I18N - encoding detection limited for output window and other areas
Status: RESOLVED WONTFIX
Product: platform
Classification: Unclassified
Component: Output Window
3.x
Sun Solaris
: P2 (vote)
: 6.x
Assigned To: Milos Kleint
issues@platform
: I18N
: 23040 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-27 18:05 UTC by Ken Frank
Modified: 2008-12-22 09:51 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2002-03-27 18:05:59 UTC
From what I've learned, the output window and some
other parts of nb, just passes
thru information it receives from outside processes.
Sometimes this information might be in other encodings.
And we've seen other issues, like 18866 or 20331 for
output window, or some other issues for exception window,
where the information is not shown correctly, so the user
cannot understand what the messages are saying.

This request is for some amount of encoding detection to be
done for output window and other windows that might show
messages from outside processes; we think this would be
very helpful for Japanese users.

ken.frank@sun.com
03/27/2002
Comment 1 Marek Grummich 2002-07-22 08:32:19 UTC
Target milestone was changed from '3.4' to TBD.
Comment 2 Marek Grummich 2002-07-22 08:41:07 UTC
Target milestone was changed from '3.4' to TBD.
Comment 3 David Strupl 2002-07-23 15:12:57 UTC
While I agree that it might be usefull I don't see any way how to
detect the encoding in which the input data are comming into NB
platform. So I am marking this issue as wontfix. Please reopen only in
case someone is able to supply a suggestion how this could possibly be
implemented.
Comment 4 Ken Frank 2002-07-30 17:16:34 UTC
Several high level suggestions obtained from some i18n resources:

1. Is there a most common group of outside processes whose
data is received by nb and shown in output window and other places ?
(like from app servers and databases ?)

If so, find out what the data transfer encoding is of those and
then have encoding conversions done using java api.

2. Often, if user is running in ja locale, it can be probable
that messages from outside process might be in some ja encoding,
but just not want nb is running in or utf-8.

In this case, there is a Japanese autodetect converter in jdk
which might be able to detect between sjis, euc and iso2022
ja encodings, and that, combined with possibility that it is encoded
in utf-8, might solve many issues at least for Japanese encodings,
and at moment, Japan is only localization done for FFJ.

3. If xml is used as data transfer, the xml standard specifies
how to detect the encoding.

ken.frank@sun.com
07/30/2002
Comment 5 Ken Frank 2002-07-31 04:48:42 UTC
More information on using Japanese encoding detection provided
by java.io.InputStreamReader. This can detect if its euc or sjis
or iso2022 encodings. 

Request JISAutoDetect as the character encoding for 
this call.  It's not yet in java.nio apis yet.

See
http://java.sun.com/j2se/1.4/docs/guide/intl/encoding.doc.html

and the various java apis.

If encoding is in utf-8 already, is there a way to detect that
or might that be the fallback if its not in one of the Japanese
encodings ?

ken.frank@sun.com
07/30/2002
Comment 6 Ken Frank 2002-09-03 21:45:35 UTC
As David has requested below, I'm reopening since have provided
information related to doing encoding detection.

ken.frank@sun.com
Comment 7 akemr 2002-09-06 14:07:06 UTC
*** Issue 23040 has been marked as a duplicate of this issue. ***
Comment 8 Ken Frank 2002-10-11 22:07:11 UTC
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.
ken.frank@sun.com
Comment 9 David Strupl 2002-10-16 10:12:41 UTC
Ken - this is an enhancement request IMHO. I don't agree with marking
this as defect - there is some functionality missing, not wrong. If
you think that this really should be done, you will have to find
resources for this feature to be done. Cc-ing Jan Chalupa from the QA
to be aware of the problems. As for the details provided - I haven't
evaluated them yet - I would do that only after it is decided that
this will be implemented for the next release.
Comment 10 Jesse Glick 2002-12-23 16:36:03 UTC
Consistent use of the I18N keyword.
Comment 11 Marian Mirilovic 2003-03-13 13:44:02 UTC
Changed owner David S. -> David K.
Comment 12 Marian Mirilovic 2004-01-14 15:25:08 UTC
changing owner dkonecny -> pnejedly
Comment 13 _ rkubacki 2007-03-14 10:48:07 UTC
output is better component IMO
Comment 14 Milos Kleint 2007-04-13 15:59:57 UTC
output module is always passed Strings from the api users.
internally it stores the information in UTF-16.

It's generally the responsibility of the codebase that reads the file to figure
out the encoding right. Since 6.0 we have FileEncodingQuery tat could help with it.

Marking as wontfix.


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