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.

Bug 148739 - I18N - Property files encoding can't be detected correctly
Summary: I18N - Property files encoding can't be detected correctly
Status: RESOLVED DUPLICATE of bug 139484
Alias: None
Product: groovy
Classification: Unclassified
Component: Grails (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: martin_adamek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-30 13:41 UTC by kaa
Modified: 2008-10-30 14:25 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
image (143.29 KB, image/jpeg)
2008-09-30 13:42 UTC, kaa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kaa 2008-09-30 13:41:48 UTC
Product Version: NetBeans IDE Dev (Build 200809221401)
Java: 1.6.0_06; Java HotSpot(TM) Client VM 10.0-b22
System: Windows XP version 5.1 running on x86; MS932; ja_JP
I'm running in Japanese locale, using a pseudo localized Netbeans with font size 16 option. 

1. Create Grails Application
2. Open Japanese properties in the editor: Message Bundles -> messages.properties -> ja

Japanese content in the file looks not encoded. All multibyte chars are shown incorrectly (see image). Probably it is
expected to have their codes instead of bad mbyte chars. The same problem happens on Solaris, ja locale utf-8 and euc
encoding. Using terminal under ja utf8 locale the content looks ok.

Also, there is an issue 139484 about Grails project encoding property. It is not implemented yet and it might be the
problem. Property files like these don't have any encoding tag (they are text files) and the encoding can't be detected.
Comment 1 kaa 2008-09-30 13:42:27 UTC
Created attachment 70893 [details]
image
Comment 2 martin_adamek 2008-09-30 15:13:57 UTC
I think it is basically duplicate of 139484. Grails projects have feq implemented, but it is hardcoded to UTF-8.

*** This issue has been marked as a duplicate of 139484 ***