[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: U+2018 symbol U+2019
From: |
Bruno Haible |
Subject: |
Re: U+2018 symbol U+2019 |
Date: |
Sat, 26 Nov 2011 19:08:32 +0100 |
User-agent: |
KMail/1.13.6 (Linux/2.6.37.6-0.5-desktop; KDE/4.6.0; x86_64; ; ) |
Paolo Bonzini wrote:
> >> 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
I don't think this would be wise. The transformation rules are heuristics.
There will likely be a few cases where they don't work right and the
address@hidden files will have to be adjusted by hand. Therefore I don't
believe that hardcoding a string-to-string transformation in glibc
is the right thing to do.
> >> - 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?
Would be fine with me. All you have to change is the function gettext_quote
in gnulib/lib/quotearg.c.
Bruno
--
In memoriam Gavriel Holtzberg <http://en.wikipedia.org/wiki/Gavriel_Holtzberg>