Bug 329424 - [nls tooling] Support for .properties file encoding other than ISO-8859-1 with Java 1.6
Summary: [nls tooling] Support for .properties file encoding other than ISO-8859-1 wit...
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.7   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-04 06:47 EDT by Deepak Azad CLA
Modified: 2016-05-31 03:05 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Deepak Azad CLA 2010-11-04 06:47:27 EDT
Java 1.6 supports loading properties file with different encodings than ISO-8859-1. (see ResourceBundle.getBundle(...) methods which take a parameter of type ResourceBundle.Control)

Eclipse nls tooling should also support different encodings
- Externalize wizard - This will use unicode escapes even if not needed
- Hovers showing NLSed strings
- Find Broken Externalized Strings ?

For eclipse style NLS, org.eclipse.osgi.util.NLS will also have to support to load .properties file with different encoding other than ISO-8859-1
Comment 1 Markus Keller CLA 2010-11-04 15:16:19 EDT
> For eclipse style NLS, org.eclipse.osgi.util.NLS will also have to support to
> load .properties file with different encoding other than ISO-8859-1

That would be quite difficult to implement:

 1. org.eclipse.osgi is restricted to OSGi/Minimum-1.2 (which is 1.4-based), so Properties#load(Reader) could only be called via a reflection hack.

 2. The encoding of a *.properties file is only known in the workspace. This information would somehow need to flow into the NLS class at run time (when the workspace is not available). This could theoretically be solved with a string that is passed to NLS.initializeMessages(..), but this somehow needs be synchronized with the encoding of the *.properties file in the workspace.
Comment 2 Dani Megert CLA 2010-11-05 04:04:59 EDT
(In reply to comment #1)
> > For eclipse style NLS, org.eclipse.osgi.util.NLS will also have to support to
> > load .properties file with different encoding other than ISO-8859-1
> 
> That would be quite difficult to implement:
> 
>  1. org.eclipse.osgi is restricted to OSGi/Minimum-1.2 (which is 1.4-based), 
Not really: The NLS class can offer a load(...) method so that reading (or even Properties creation) is delegated.

>  2. The encoding of a *.properties file is only known in the workspace. This
> workspace is not available). This could theoretically be solved with a string
> that is passed to NLS.initializeMessages(..),
Right. Our message class already has meta information that points to the properties file (BUNDLE_NAME). We could just add the encoding info as well and have the 'Find Broken NLS Strings' action detect incompatibilities.