Consistent encoding strings

[koppor]

JabRef's current encoding list lists possible encodings.

The strings have flaws:

• UTF8 and UTF-16 are possible encodings. I really dislike the inconsistency between them: UTF8 has no -, but UTF-16 has: Both should have a dash resulting in UTF-8. (see https://de.wikipedia.org/wiki/UTF-8)
• Cp1251 should be CP1251 (see http://man7.org/linux/man-pages/man7/cp1251.7.html for example). Similar for all other code pages
• ISO8859_15 should be ISO8859-15 (see https://de.wikipedia.org/wiki/ISO_8859-15). Similar for all other encodings

On the one hand, I am very well aware that a change here results in a large compatibility code where the old strings have to be mapped to the new strings. On the other hand, I would like to see JabRef having strings not causing confusion.

Related: #118, #131

[lenhard]

I fully agree with what you write and just had a look at this issue.

As far as I can see, we can just replace the faulty names with the correct ones in ALL_ENCODINGS and add the correct names to ENCODING_NAMES_LOOKUP. This means we have two keys (the correct name and the old name) for the same encoding. This should not break anything, since ALL_ENCODINGS is only used to display available encoding names in the UI and ENCODING_NAMES_LOOKUP is used for for actually applying an encoding. Hence, duplicate keys won't hurt as long as the values are ok (which, I assume, they are).

To sum up: This change looks pretty easy to me, but perhaps I just overlooked a difficult problem. Can you point me to code that breaks with the above changes?

[simonharrer]

Can the user select the encoding in the UI? Do we want to automatically upgrade from an old encoding name to the new encoding name? Where are the used encodings stored?

[lenhard]

• Can the user select the encoding in the UI?

Yes, at various positions, for instance when a save action fails with an UnsupportedCharsetException. Example code is:

Object choice = JOptionPane.showInputDialog(frame, Localization.lang("Select encoding"), Localization.lang("Save database"),
                        JOptionPane.QUESTION_MESSAGE, null, Encodings.ENCODINGS, encoding);

• Do we want to automatically upgrade from an old encoding name to the new encoding name?

Can you describe some more what exactly you mean by automatic upgrade? Me changing source code would be a manual upgrade.

• Where are the used encodings stored?

Encodings are stored in the Encodings class as linked by Olly above.

[koppor]

• Do we want to automatically upgrade from an old encoding name to the new encoding name?

Yes! I know that this will introduce backward compatibility issues. However, we should move forward ^^.
(I think Simon meant the encoding string in the .bib file)

[simonharrer]

👍

Automatic upgrade: replace the encoding in the first line of the .bib file with a newer encoding: utf8 --> utf-8

Are encodings stored in the preferences as well? Do we have to upgrade there, too?

[lenhard]

Are encodings stored in the preferences as well? Do we have to upgrade there, too?

I have no idea, but would be very glad if you find out :)

[simonharrer]

JabRefPreferences.DEFAULT_ENCODING can be selected from the list of encodings. Hence, it can contain an old encoding which would need to be migrated to a newer one as well.

[lenhard]

The only critical position where encodings were hardcoded were the preferences. Thanks @simonharrer!

I added compatibility code to automatically update the preferences and this issue should be fixed.