[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] U+2018 symbol U+2019

From: Paolo Bonzini
Subject: Re: [bug-gettext] U+2018 symbol U+2019
Date: Sat, 26 Nov 2011 17:15:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1

On 11/26/2011 03:27 PM, Bruno Haible wrote:
- gnulib needs to add support for address@hidden and address@hidden in gnulib's
bootstrap script.

If you want so, why not. It's not that complicated. Take the rules from
gettext's Rules-quot, quot.sed, boldquot.sed files.

Yes, I'll look into it.

- perhaps if we cannot convince distributions to use quot locales more

Yes, if a number of English users use these locales and report no problems
with then, it would make sense for distributions to use them by default
when the user selects "English".

We should first support them in gnulib first, so that most command-line programs gain the support, and do new releases of the GNU utilities. We should also try to understand how GNOME works in this respect (I'd guess it uses '...' rather than `...').

gettext should be changed to use them by default

I don't understand what you mean here. gettext() in libc or libintl has generic
mechanisms for dealing with locale names and understands @quot suffixes.

I meant embedding the transformation rules in gettext(), without requiring the explicit generation of @quot

- for programs not using gettext, we could perhaps add a gnulib module
that automatically provides a coding of U+2018/U+2019, like this:

          printf ("foo %s %s\n", lq(), rq());

Stylistically, the gnulib quotearg module is preferable.

WDYT about making quotearg use U+2018/U+2019 by default in UTF-8 locales even if there are no translations?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]