On 11/26/2011 03:27 PM, Bruno Haible wrote:
- gnulib needs to add support for en@quot and en@boldquot 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
