Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 351700

Summary: Cannot use UTF-8 for Bundle-Localization file
Product: [Eclipse Project] Equinox Reporter: Pavel Sklenak <pavel.sklenak>
Component: FrameworkAssignee: equinox.framework-inbox <equinox.framework-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: jgawor, jwross, kitlo, remy.suen, tjwatson
Version: 3.7   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard: stalebug

Description Pavel Sklenak CLA 2011-07-11 08:20:49 EDT
Build Identifier: 20110615-0604

http://wiki.eclipse.org/Eclipse_Globalization_Guidelines#All_ResourceBundle_file_contents_should_be_encoded_in_UTF-8

I encoded properties files in UTF-8 for RAP application and it works well. However, e.g. view name (defined via plugin.xml and externalized) ignores setting to UTF-8 and shows mismatch.

Reproducible: Always
Comment 1 Thomas Watson CLA 2011-07-14 14:47:28 EDT
What confuses me about the referenced guideline is that the Properties.load method, which ResourceBundle uses under the covers to load the localization properties files, only supports ISO 8859-1.  So I don't see how the guideline could result in ResourceBundle properties files that would be loaded successfully by the ResourceBundle class in Java.

See http://download.oracle.com/javase/6/docs/api/java/util/Properties.html#load%28java.io.InputStream%29
Comment 2 Thomas Watson CLA 2011-07-14 14:51:59 EDT
Perhaps Kit could shed some light on this subject.
Comment 3 Kit Lo CLA 2011-07-14 16:14:36 EDT
Actually, the guideline was a little mis-leading. We just meant the communication between developers and translators (the sending and receiving) should be in UTF-8. Most Java resource bundle files are created in English, which is in 8859-1. So, we should not have problems with the source files. When we receive the translated files from translators, we have to use the Java util "native2ascii" to convert the UTF-8 files to escaped Unicode. After that, all characters will in the Latin character set (with some characters in \uxxxx format), which is in 8859-1.
Comment 4 Pavel Sklenak CLA 2011-07-18 07:56:00 EDT
e.g. RWT.NLS.getUTF8Encoded() supports UTF-8 encoded resource bundles.

It would be nice to have something like "Bundle-Localization: plugin;encoding=UTF-8"

http://download.oracle.com/javase/6/docs/api/java/util/Properties.html#load%28java.io.Reader%29 (since 1.6) can use specific encoding.
Comment 5 Thomas Watson CLA 2011-07-18 09:36:48 EDT
(In reply to comment #4)
> e.g. RWT.NLS.getUTF8Encoded() supports UTF-8 encoded resource bundles.
> 
> It would be nice to have something like "Bundle-Localization:
> plugin;encoding=UTF-8"
> 
> http://download.oracle.com/javase/6/docs/api/java/util/Properties.html#load%28java.io.Reader%29
> (since 1.6) can use specific encoding.

Moving to Equinox.  But I am not sure I like the idea of a directive.  UTF-8 reader can read ISO 8859-1.  I guess the only reason is to provide failure of UTF-8 is not supported.  But current Equinox does not support reading UTF-8 and is not going to start providing an error.  Also note that the NLS class in Equinox also only supports 8859-1.  Support for UTF-8 will require Java 6.

I think an OSGi bug is warranted at https://www.osgi.org/bugzilla/ before introducing any Equinox specific directives.
Comment 6 Lars Vogel CLA 2019-11-14 03:42:17 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

If the bug is still relevant, please remove the "stalebug" whiteboard tag.
Comment 7 Thomas Watson CLA 2019-11-14 08:48:57 EST
No plans to address this.