Are you entering unicode directly into popt table strings?

If so, then use gettext(3) and a N_("...") wrapper.

There are still issues with unicode and alignment: popt does not use
wide characters (which were largely non-existent outside of M$ when
popt was written).

The remaining issues cannot be easily resolved (I've tried many things)
because popt also undertakes a UTF8 -> non-UTF8 conversion for GNOME
which makes WYSIWYG nearly impossible to test.

73 de Jeff
On Nov 24, 2013, at 11:24 AM, Robert Scheck wrote:

> Hello all,
> I am forwarding a message of Christoph Anton Mitterer (Cc'ed) which was
> reported at Red Hat Bugzilla. However this does not feel for me like a
> downstream thing but more relevant for popt upstream, thus relaying it:
> ----- Forwarded message -----
> Hi.
> Popt has apparently problems with unicode characters.
> I tried to include some in the descrip and argDescrip field of the
> option table, e.g.
> - either directly "foo“”bar"
> - or escaped "foo\u201c\u201dbar"
> and then using the auto help functionallity.
> popt reacts quite strangely sometimes it justs works and the characters
> are printed correctly, sometimes it however skips the unicode characters
> and all between them, but not necessarily for all the unicode characters
> used
> ie.
> "\u201cfoo\u201d bar \u201cbaz\u201d"
> may become
> bar “bar”
> when printed.
> Cheers,
> Chris.
> ----- End forwarded message -----
> Foreign references for this request are:
> -
> -
> Greetings,
>  Robert

POPT Library                                 
Developer Communication List             

Reply via email to