Translated UTF-8 messages being printed to console without locale conversion

Bug #1083076 reported by Gareth Edwards
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gEDA
In Progress
High
Gareth Edwards

Bug Description

Split from bug 698498 so it can be worked on independently:

"_() translated messages are being printed to stderr / stdout, wihthout any regard for converting to the system encoding.

This results in garbled console output where the console / system locale isn't UTF-8."

Tags: i18n sf-bugs
tags: added: i18n sf-bugs
Changed in geda:
importance: Undecided → High
status: New → In Progress
assignee: nobody → Gareth Edwards (gareth-uk)
Revision history for this message
Peter TB Brett (peter-b) wrote :

Have you had any thoughts on what the best way to approach this would be?

Revision history for this message
Vladimir Zhbanov (vzhbanov) wrote :

Hi, I have two solutions for this. One of them actually works :)
See the patches attached below.

The first of them changes the codeset used in gschem. I tried it
in mixed environment (in my system, the default locale is
ru_RU.UTF-8, but I used the koi8rxterm program from the xterm
package and LANG=ru_RU.KOI8-R; the 'mixed environment' means that
in this case gschem still writes text files using UTF-8).

However, with this patch gschem outputs many
  Gtk-WARNING **: Invalid input string
and segfaults. gdb says:
  Segmentation fault.
  0xb77e7108 in g_markup_escape_text () from /lib/libglib-2.0.so.0
I don't know why, maybe because of the mixed environment, or just
libglib doesn't support KOI8-R now.

I cannot check the patch on a clean system but I believe what I
have tried with LANG=KOI8-R is enough to consider this way wrong.

The second patch just resets the internal gschem encoding to C if
a user uses any non-UTF-8 encoding. I consider this to be better
since
  1) I believe we aim at universality and want to support UTF-8
     anywhere so we have to by all means encourage users to do it
     and force them to throw out their obsolete other encodings.
  2) it doesn't segfault :)

In order to quickly check how it works you may add the following
string somewhere in gschem:
  #define DEBUG 1
and run it in your terminal with changed LANG (you have to install
a new locale which will be used first). gschem will output some
info.

Revision history for this message
Vladimir Zhbanov (vzhbanov) wrote :
Revision history for this message
Vladimir Zhbanov (vzhbanov) wrote :
Revision history for this message
gpleda.org commit robot (gpleda-launchpad-robot) wrote :

A commit was made which affects this bug
git master commit 131e7f6260e8c67e32997f78b9f853219bd26ebd
http://git.geda-project.org/geda-gaf/commit/?id=131e7f6260e8c67e32997f78b9f853219bd26ebd

commit 131e7f6260e8c67e32997f78b9f853219bd26ebd
Author: Vladimir Zhbanov <email address hidden>
Commit: Vladimir Zhbanov <email address hidden>

    libgeda: fix localization of guile messages

    This patch fixes guile output in localized environments where guile
    outputs unicode sequences in form /uXXXX instead of localized strings.
    This affects output to the terminal as well as to the gschem log window.

    Probably, the issue has been introduced in guile 2.0. See discussion
    at http://lists.gnu.org/archive/html/guile-user/2013-08/msg00066.html.

    Affects-bug: lp-1083076

Revision history for this message
Vladimir Zhbanov (vzhbanov) wrote :

Hi, Gareth.

Please look at the commit 131e7f6 to see if this patch fixes the bug.

Thanks,
  Vladimir

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.