Bug 173411 - Elinks translations not in UTF-8
Elinks translations not in UTF-8
Product: Fedora
Classification: Fedora
Component: elinks (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
: 173409 173410 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-11-16 18:40 EST by Kevin Kofler
Modified: 2008-07-02 05:47 EDT (History)
0 users

See Also:
Fixed In Version: elinks-0.12-0.1.pre1.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-02 05:47:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kevin Kofler 2005-11-16 18:40:22 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.2 (like Gecko)

Description of problem:
The translations of elinks are apparently not in UTF-8. This leads to menus 
etc. not displaying special characters correctly. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open a terminal emulator with UTF-8 support (gnome-terminal, Konsole, ...).   
2. LANG=de_AT.UTF-8 elinks (You won't notice the problem with English.)  
3. Look at the title of the appearing "URL Oeffnen" ("Go to URL") window.   

Actual Results:  The umlaut O ("Oe") in "Oeffnen" (Bugzilla won't let me enter the umlaut) 
isn't displayed properly.  

Expected Results:  The umlaut should display correctly. 

Additional info:

This also affects other translations, such as French.
Comment 1 Kevin Kofler 2005-11-16 18:41:22 EST
The Title should be rendered as "URL Öffnen". 
Comment 2 Karel Zak 2005-11-18 05:19:10 EST
It's already know problem that elinks is internaly UTF8 unfriendly. It's thing
that should be fixed by upstream developers, because it requires deep changes in
elinks source code. Sorry.
Comment 3 Kevin Kofler 2005-11-18 13:28:05 EST
But wouldn't recoding the translation files to UTF-8 fix that particular issue? 
Comment 4 Karel Zak 2005-11-21 07:14:16 EST
No, it's only workaround for subset of UTF8 encodings -- for example for Asian
encodings we need a change in source code, because one letter != one cell
("glyph") on the screen.
Comment 5 Kevin Kofler 2005-11-21 07:17:24 EST
Good point, but isn't it better to have a few dozen working locales and half a 
dozen broken ones than to have dozens of broken locales and 1 (US English) 
Comment 6 Karel Zak 2006-02-21 10:46:32 EST
*** Bug 173409 has been marked as a duplicate of this bug. ***
Comment 7 Karel Zak 2006-02-21 10:46:51 EST
*** Bug 173410 has been marked as a duplicate of this bug. ***
Comment 8 Kevin Kofler 2006-10-24 17:13:32 EDT
Still applies to elinks-0.11.1-5 in FC6.
Comment 9 Karel Zak 2006-11-20 19:37:51 EST
I wait for an upstream fix. They know about this elinks limitation and I hope
they will fix the problem in future.
Comment 10 Ondrej Vasik 2007-06-06 09:02:13 EDT
Just tried with elinks-0.12-unstableGITsnapshot from upstream and problem seems
to be fixed there. So after release of stable 0.12 tarball will be fix hopefully
included in next release of Fedora.
Comment 11 Till Maas 2008-01-05 08:39:49 EST
This bug is still there in Fedora 7.
Comment 12 Kevin Kofler 2008-01-05 08:45:53 EST
And Fedora 8.
Comment 13 Ondrej Vasik 2008-01-07 03:51:19 EST
Yes, 0.12 is still not released - there are still some tasks opened. There is no
planned date of release so far I know. Sorry for that, but there are some
regressions against 0.11.3 and they have to be fixed and backporting of UTF-8 to
0.11.3 is too complex.
Comment 14 Ondrej Vasik 2008-07-02 05:47:03 EDT
Upstream released 0.12pre1, in general better than stable 0.11.4, therefore
using it in RAWHIDE. This issue is solved by 0.12pre1, but backport to 0.11.4 is
too complex. Closing RAWHIDE as I don't plan upgrade to unstable 0.12pre1 in
released Fedora's.

Note You need to log in before you can comment on or make changes to this bug.