Community
Participate
Working Groups
20020723 The names of all of the encodings is shown differently in the pull down menu and on the preference page. Specifically Latin 1 is on the pulldown and ISO- 8859-1 is shown on the preference page. I think the preference page is the better choice.
I actually prefer the Edit / Encoding presentation since it is more user- friendly. Compare with IE's encoding menu. However, I know of no way of getting human-readable names for encodings through standard Java API. If there is no way to do this with generic API, we should just hardwire a bunch of names like IE, and translate them. We should at least include encodings for the main locales we support. Better yet would be a way to extend the list. E.g. the Japanese translation fragments could add the Japanese encoding(s).
Are the encodings the sort of thing that translators should handle? I think we might want to do it like we do with the key bindings - i.e. add an extension point for encodings that has an optional locale tag and define a few of those we know about with the option for fragments to extends. Something like <fileencodings id="defaultencodings" <fileencoding id="Latin-1" /fileencoding> <fileencoding id="GBK" locale="ja" /fileencoding> <fileencodings>
Yes, something like that. We should have a good basic set, and translation fragments could add more.
Fixed in Stream TC_ENCODING. Will be released pending approval by Kai.
Java already supports a large number of encodings that aren't on your list. It would be better to use the IANA names for encodings in the UI and the Java names only internally.
When the encoding changes are released we can see what other additions we are after. The new encoding work has the concept of a label (which is what the user sees) and a value (the actual encoding value java would use) which should address your concerns. Here is an example of the plugin.xml <extension point="org.eclipse.ui.fileEncodings"> <fileEncoding id="GB18030" label= "%FileEncoding.GB18030" value="GB18030" helpContextId="GB18030_action_context" description="%FileEncoding.GB18030.description" tooltip="%FileEncoding.GB18030.tooltip" locale="zh_CW"> </fileEncoding> <fileEncoding id="GBK" label="%FileEncoding.GBK" value="GBK" helpContextId="GBK_action_context" description="%FileEncoding.GBK.description" tooltip="%FileEncoding.GBK.tooltip" locale="zh"> </fileEncoding> <fileEncoding id="ISO-8859-1" label="%FileEncoding.ISO-8859-1" helpContextId="ISO-8859-1_action_context" description="%FileEncoding.ISO-8859-1.description" tooltip="%FileEncoding.ISO-8859-1.tooltip" value="ISO-8859-1"> </fileEncoding> <fileEncoding id="UTF-8" label="%FileEncoding.UTF-8" helpContextId="UTF-8_action_context" description="%FileEncoding.UTF-8.description" tooltip="%FileEncoding.UTF-8.tooltip" value="UTF-8"> </fileEncoding> <fileEncoding id="UTF-16" label="%FileEncoding.UTF-16" helpContextId="UTF-16_action_context" description="%FileEncoding.UTF-16.description" tooltip="%FileEncoding.UTF-16.tooltip" value="UTF-16"> </fileEncoding> <fileEncoding id="UTF-16BE" label="%FileEncoding.UTF-16BE" helpContextId="UTF-16BE_action_context" description="%FileEncoding.UTF-16BE.description" tooltip="%FileEncoding.UTF-16BE.tooltip" value="UTF-16BE"> </fileEncoding> <fileEncoding id="UTF-16LE" label="%FileEncoding.UTF-16LE" helpContextId="UTF-16LE_action_context" description="%FileEncoding.UTF-16LE.description" tooltip="%FileEncoding.UTF-16LE.tooltip" value="UTF-16LE"> </fileEncoding> <fileEncoding id="US-ASCII" label="%FileEncoding.US-ASCII" helpContextId="US-ASCII_action_context" description="%FileEncoding.US-ASCII.description" tooltip="%FileEncoding.US-ASCII.tooltip" value="US-ASCII"> </fileEncoding> </extension>
I'm hopeful. But it sure won't address my concern if Eclipse has its own set of encoding labels, different than IANA or Java. ;-} It's all very well to define the labels in XML, but if it's like the keyboard shortcuts, they all tend to go in platform.ui where plugins and users have very little say in the matter. What is locale= used for? Is there any design document for the encoding changes? I hope it's realized that when it comes to encoding one size does not fit all. For example, auto-detection is mandatory for XML. I basically disabled the current encoding support for my XML editor (took it out of the menu, overrode the document provider). The only part left is the workplace default encoding, which a user can choose to use as a preference option.
The locale tag is for encodings that are only relevant in certain locales (like GB18030 in Simplified Chinese).
How do you know in what locales an encoding is relevant? Put another way, how do you know that the Unicode support in some platform isn't sufficiently strong to display these encodings, regardless of the locale?
It is more a question of what we add as code pages by default - you can add in a locale by typing the encoding into the preference page. Removing code pages that are not generally interesting outside of a particular locale (like GB18030) is just a way of reducing the list size.
That makes sense but it seems to add work to do it right. That means that once the user has ever specified an encoding not in the default list it should thereafter appear in the list, which means it has to be saved somewhere, etc. (But you always have to allow for encodings you don't know about, so maybe that just goes with the territory.) The next shoe to drop will be someone wanting an option to see the entire list rather than have to type in an encoding with the attendant possibility of error. BTW, is there any design document about the encoding changes?
The changes described here are just a simple UI addition - the encoding is due to be revisited as a whole soon - there should be documentation forthcoming then.
There's now API (WorkbenchEncoding and IDEEncoding) to get a list of encodings (see bug 34421). To adopt this we need to: - remove our hard-coded encoding commands - deprecate the constants - replace the constants with dynamic values
We no longer provide custom encoding change actions in the editor. Instead we retarget the PROPERTIES command (open properties dialog) which allows to change the encoding. In addition we provide a Change Encoding... action which uses the Platform UI's ResourceEncodingFieldEditor. This has been committed to HEAD. Released into I200409211600
