Change file encoding on the fly

Thanks for your bug. That's known upstream: http://bugzilla.gnome.org/show_bug.cgi?id=342918

I'm write gedit plugin to fast reopen the file with any encoding, defined in the Open/Save dialog.
To install, extract content of the encoding.tar.gz to ~/.gnome2/gedit/plugins/

The plugin does not work. When I install it, I go to "Plugins" tab in settings dialog and select the plugin. It stays not selected and becomes grey (unselectable).

I just cleaned all my configuration for gedit and everything works.

I just want to add that I just had similar problem.
I opened cp1250 encoding text file. Gedit opened it incorrectly as iso-8859-2 file thus making it hardly readable.
I tried the same file in Leafpad - worked fine (probably has some type of guessing algorithm).
I tried it in Geany - opened wrong, similar to gedit, but there is an option to "reopen file with encoding..."
So I reopened it in Geany as cp1250 encoding, changed to utf8 and saved.

After that, Gedit informed me that file changed on filesystem and after reload - it was even much worse. Gedit apparently reloaded without checking encoding again.
I closed Gedit and opened the file again in Gedit. Everything was fine, it correctly recognized utf8.

So in conclusion:
1) Gedit is unable to recognize cp1250 encoding (at least, did not try any other) - which is probably intentional lack of feature. Fine, maybe in future?
2) Gedit lacks an easy way to reload file with user chosen encoding - which is a pitty, I think. I even thought I cannot choose encoding at all in Gedit until I read first comments in this thread. (I usually open files directly from nautilus.)
3) Gedit, when reloading file after io filesystem change, does not check for change in encoding. This is, I think, the worst of these three. Gedit knows that something has happened with the file, so there is no reason to suppose that it should not have been change in encoding, is it? Therefore encoding should be checked as well, when reloading already opened file.

That is all I found about that, hope it helps somehow.

I also attached that file, just in case...

This is very annoying bug, every time I encounter external text files, as they are always in windows encoding

plugin which was given in upstream bug still works in jaunty.
please consider adding it

That's actually a bug, not wishlist item. Gedit shows that it can detect any encoding of the file but actually it detects only KOI-8 and UTF-8. Moreover there is no way to open a file in any other encoding than UTF-8 or KOI-8.

So it is a bug with normal priority.

I also think so.

Actually, for me it only detects UTF-8 and Latin-15. I even tried to open a KOI8-U text file on gedit, and it was rendered as Latin-15. Perhaps it depends on the locale?

While a fix is released, here's a workaround:
1- Open the text file with Firefox.
2- Select the correct character encoding.
3- Copy the text and re-save the file as UTF-8.

Anyway, I do think this should be a normal bug with normal priority - one should not have to resort to a full-fledged web browser (one which is a resource hog, even) to read a simple text file.

There is easier workaround:

user@host $ sudo apt-get install kwrite

It has too many dependencies, while Firefox comes by default on most Ubuntu systems.

Guys, do not quarrel over workaround. ;-)
All text editors like for example geany, leafpad, kate or nano may be used. As I wrote, I used geany to change file encoding. Worked fine.
You do not even need any other app to solve the issue, gedit is just enoug. But it forces you to do unexpected things and thus making gedit user-unfriendly. :-(

You can choose encoding when opening file from inside gedit (open file form). And then save it using gedit as whatever encoding you need.

patch for this issue available at http://bugzilla-attachments.gnome.org/attachment.cgi?id=134201
Why current version gedit build without this patch?

Perhaps it is because it hasn't officially been accepted?

As a workaround you might also want to modify the list of automatically
detected code pages in gedit, there is a key for that in GConf:

/apps/gedit-2/preferences/encodings/auto_detected

Not on-the-fly, but solves general cases by removing the cause…

KWrite has also automatic encoding detection and it works perfect (my CP-1251 files are read in CP-1251 and UTF-8 files are read in UTF-8).

P. S. This is bug, not a wishlist.

I want this report be bug, not wishlist.

from release to release, it is pain for Russian users, to switch encodings by closing file, finding path where it was opened originally, set encoding in combobox.

Да, меня просто достало это в gedit :). Еще немного и я таки сам наверно запатчу это.

This is annoying, I wish there is a plugin or something resides in the menu that by clicking it I could change the encoding used to interpret the text in the current tab.
thank you.

> I want this report be bug, not wishlist.
This statement also counts as a wishlist item, mind you.

> This is bug, not a wishlist.
Why? Gedit works fine, but generally lacks a feature to read user's mind… and, perhaps a way to tell it what code pages you normally use from within its preferences (something like editing the list in the open dialog), and, as mentioned in the ticket, an option to switch code pages on-the-fly. A missing, but desired feature, hence the wishlist status.

For those annoyed by the close-open-with-selected-encoding procedure: Read comment #16. Its not an obvious fix, but please take a minute or two to apply it, and you will probably be relieved from some extra frustration.

> I wish there is a plugin or something…
By the way, did you try searching?
http://code.google.com/p/gencodingconverter/

Sorry, I meant the other plugin (to reopen, not to convert):
https://bugzilla.gnome.org/show_bug.cgi?id=342918#c7

toAlexander A.:
Read my comment #5 - points 1 and 2 are probably more like wishlist items, while point 3 is clearly a bug (well, other than directly described by subject of this issue).

This is definitely bug of this peace of software, that's why:
if you doing some action with user data - do it best possible way OR warn user about low quality / no guaranty of this action.

In this case if gedit so stupid, that can't use already existing library from kedit to guess file encoding, it should't try to do it at all, just show to user dialog with encoding selection, instead of give dummy result, that definitely useless at all.

As Alexander A. suggested workaround is:
open in gconf-editor:
/apps/gedit-2/preferences/encodings/auto_detected
and put cp1251 or other your native most common encoding to the top.
This stops works with retarded KOI8-R, but UTF-8 will continue work as usual.

PS: I'm not using linux for a wile exactly for this reason, usability level here sometimes good, sometimes terrible and nobody cares - instead of fixing usability bugs before release new features with same mistaces (or simpler just bugs) it storing in long-term wish-list, es example - Evolution.

One can easily reopen a document with desirable encoding using "Encoding" plugin included in gedit-gmate package which comes from ubuntu-on-rails ppa. UTF-8, windows-1251 and western iso-8859-15 are in the list. Don't know if other encodings support can be added, but 1251 will do for me.
Found it here: http://youtu.be/tquErQhPk60