[Dropping bug-texinfo from CC.]
The en@quot and en@boldquot mitigate the problem that
- For English, there is no translation team,
- Source code that contains gettext calls, like in _("hello `world'"),
use ASCII quotation mark approximations.
Paolo Bonzini wrote:
> [gettext should] build @quot variants for other languages too?
That would not make sense in general. For other languages, the translation
teams are already widely using the appropriate quotation marks. Most
translations are being submitted in UTF-8 format, and convertibility to
ISO-8859-1 is a requirement any more: Users who live in a constrained
environment with only an ASCII locale can use the "C" locale.
Some PO files for other locales can be automatically generated from other
PO files. If a translator community approaches me with it, such a
transformation rule can be installed in the Makefile.in.in.
> Possibly with a custom quoting
> choice for each language, e.g. guillemets for French and U+300C/U+300D
> quotes for CJK (like 「鉤括弧」).
The translators already handle this. gnulib's quotearg module uses the
quotation marks that the translators have provided.
> - 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.
> - 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".
> 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.
> - 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.
> Then of course all this should be documented in the GNU Coding
> Standards. Volunteers? :)
The first place for documenting best practices in internationalization
is the GNU gettext manual, not the GCS.
Bruno
--
In memoriam Gavriel Holtzberg <http://en.wikipedia.org/wiki/Gavriel_Holtzberg>
