Re: U+2018 symbol U+2019

[Paolo Bonzini]

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
> > extensively
>
> 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?

Paolo