Bug 173411
| Summary: | Elinks translations not in UTF-8 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kevin Kofler <kevin> |
| Component: | elinks | Assignee: | Ondrej Vasik <ovasik> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | elinks-0.12-0.1.pre1.fc10 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-07-02 09:47:03 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
The Title should be rendered as "URL Ãffnen". 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. But wouldn't recoding the translation files to UTF-8 fix that particular issue? 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.
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) working? *** Bug 173409 has been marked as a duplicate of this bug. *** *** Bug 173410 has been marked as a duplicate of this bug. *** Still applies to elinks-0.11.1-5 in FC6. I wait for an upstream fix. They know about this elinks limitation and I hope they will fix the problem in future. 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. This bug is still there in Fedora 7. And Fedora 8. 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. 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. |
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): elinks-0.10.3-3.1 How reproducible: Always 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.