Status of i18n patches

Status of i18n patches

[Martin v. Loewis]

In GCC, translators of messages are faced with significant problems
when translating them. In many cases, messages are created by pasting
fragments of sentences. While this may work for English, it fails for
other languages.

A few months ago, Paolo Bonzini has created a patch that solves some
of these problems:

http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01620.html

Can somebody please work with Paolo to apply this patch? 

If the patch is not acceptable in its current form, could someone
please give Paolo reasons for rejection?

If the patch needs to be split into several chunks, could somebody
please give Paolo directions on what parts of the patch can be more
readily integrated than others?

Thanks for your attention,
Martin

quote marks [was: Status of i18n patches]

[Per Bothner]

While we're at it, perhaps it is time to fix things like:
`%s' to '%s' - i.e. get rid of uses of 0x60 GRAVE ACCENT as
"begin single quote".  This no longer works with modern
Unicode-compatible fonts, since it is not symmetric with
0x27 APROSTROPHE (aks APOSTROPHE-QUOTE).

Unicode recommends using 0x2018 LEFT SINGLE QUOTATION MARK
and 0x2019 RIGHT SINGLE QUOTATION MARK, but that may be too
radical a choice, for now.

One option: we could have the various error routines post-process the
error message before printing.  Depending on an option or the locale
it could either emit a pair of 0x27 or a 0x2018/0x2019 pair ...
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: quote marks [was: Status of i18n patches]

[Zack Weinberg]

On Mon, Oct 14, 2002 at 09:14:20AM -0700, Per Bothner wrote:
> While we're at it, perhaps it is time to fix things like:
> `%s' to '%s' - i.e. get rid of uses of 0x60 GRAVE ACCENT as
> "begin single quote".  This no longer works with modern
> Unicode-compatible fonts, since it is not symmetric with
> 0x27 APROSTROPHE (aks APOSTROPHE-QUOTE).

While I agree that we need to make a change along these lines, I would
suggest using "%s" (0x22 QUOTATION MARK) which is reliably a neutral
(vertical) double quote.  This is already the convention in cpplib.
It is, however, mildly annoying to have to write \" all the time.

> One option: we could have the various error routines post-process
> the error message before printing.  Depending on an option or the
> locale it could either emit a pair of 0x27 or a 0x2018/0x2019 pair
> ...

An interesting idea... although, if we go with the double-quote
suggestion, it should be 0x201C/0x201D.  Don't recent versions of
gettext have the ability to recode messages on output?  Perhaps this
feature could be added there.

zw

Re: quote marks [was: Status of i18n patches]

[Paul Koning]

>>>>> "Zack" == Zack Weinberg <zack@codesourcery.com> writes:

 >> One option: we could have the various error routines post-process
 >> the error message before printing.  Depending on an option or the
 >> locale it could either emit a pair of 0x27 or a 0x2018/0x2019 pair
 >> ...

 Zack> An interesting idea... although, if we go with the double-quote
 Zack> suggestion, it should be 0x201C/0x201D. 

Quotes are language-dependent.  201c/201d may be right for English,
but not for Dutch (which uses ,, for open quote) nor French (which
quotes with << and >>), to mention just a few examples.

       paul

Re: quote marks [was: Status of i18n patches]

[Joseph S. Myers]

On Mon, 14 Oct 2002, Paul Koning wrote:

> Quotes are language-dependent.  201c/201d may be right for English,
> but not for Dutch (which uses ,, for open quote) nor French (which
> quotes with << and >>), to mention just a few examples.

Obviously each language should use the correct quotes for that language in
its message catalog.  Where this requires Unicode (as for English), the
message catalogs should be UTF-8 encoded (which, long-term, is probably
correct for all languages anyway); gettext can, with recent enough glibc
(and hopefully recent enough libiconv) translate character sets on output
with transliteration of characters not supported in the output character
set (e.g. transliterating Unicode quotes to ASCII ones for an ISO-8859-1
terminal).

I don't however know what the correct solution for English for getting
proper quotes is.  (English language users using UTF-8 will have LC_CTYPE
set appropriately, e.g. to en_GB.UTF-8, but not necessarily LC_MESSAGES.)

In any case ` is not an appropriate ASCII quote (though it is an
appropriate TeX quote, which should be used in Texinfo manuals).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: quote marks [was: Status of i18n patches]

[Per Bothner]

Paul Koning wrote:
> Quotes are language-dependent.  201c/201d may be right for English,
> but not for Dutch (which uses ,, for open quote) nor French (which
> quotes with << and >>), to mention just a few examples.

-which may be an argument for single-quotes, rather than double-quotes.

Actually, I think you're point may not be very relevant, since we're
not talking about natural language quotation, but about whatever
looks natural *to a programmer* when indicating names, not when
quoting phrases.  For example, underlining might actually be a
reasonable output format.  Or even better:  Have the phrases that
are subject to translation appear in a variable-width font, but
the names in the messages appear in a fixed-width font, like they
would in a technical article.

Perhaps we should keep `%s' in the error messages, but encourage
user interfaces (such as IDEs) to use fonts instead.  Using `%s'
makes that fairly easy.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: quote marks [was: Status of i18n patches]

[Michael Matz]

Hi,

On Mon, 14 Oct 2002, Per Bothner wrote:

> Perhaps we should keep `%s' in the error messages, but encourage
> user interfaces (such as IDEs) to use fonts instead.  Using `%s'
> makes that fairly easy.

But my GUI (xterm) can't do that easily, so to fix the inappropriate use
of ` would be worthy nevertheless.


Ciao,
Michael.

Re: quote marks [was: Status of i18n patches]

[Per Bothner]

Michael Matz wrote:
> But my GUI (xterm) can't do that easily, so to fix the inappropriate use
> of ` would be worthy nevertheless.

My suggestion is that by default (without some appropriate option
or environment variable) that gcc's message routines (error etc)
would translate the '\`' to '\''.

However, if we change the actual error messages to use '\'', then
it becomes much more difficult support the *option* to convert
then to some other format.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: quote marks [was: Status of i18n patches]

[Michael Matz]

Hi,

On Mon, 14 Oct 2002, Per Bothner wrote:

> My suggestion is that by default (without some appropriate option
> or environment variable) that gcc's message routines (error etc)
> would translate the '\`' to '\''.

Oh I see.  That would work, indeed.


Ciao,
Michael.

Re: quote marks [was: Status of i18n patches]

[Gabriel Dos Reis]

Per Bothner <per@bothner.com> writes:

| Paul Koning wrote:
| > Quotes are language-dependent.  201c/201d may be right for English,
| > but not for Dutch (which uses ,, for open quote) nor French (which
| > quotes with << and >>), to mention just a few examples.
| 
| -which may be an argument for single-quotes, rather than double-quotes.

just nit-picking: ' is apostrophe in French used for elision as in 
"l'Atlantique".

But in general I agree with: we should change `%s' to '%s' -- I think
I was already doing similar thing in new diagnostics.

-- Gaby

Re: quote marks [was: Status of i18n patches]

[Martin v. Loewis]

Zack Weinberg <zack@codesourcery.com> writes:

> > One option: we could have the various error routines post-process
> > the error message before printing.  Depending on an option or the
> > locale it could either emit a pair of 0x27 or a 0x2018/0x2019 pair
> > ...
> 
> An interesting idea... although, if we go with the double-quote
> suggestion, it should be 0x201C/0x201D.  Don't recent versions of
> gettext have the ability to recode messages on output?

glibc will do transliteration, translating 201C/201D with
0022. 2018/2019 transliterate to 0027. Dunno if standalone
gettext/iconv can also transliterate.

Relying on transliteration is encouraged in the Translation Project,
since it makes translations look nicer on modern software, while still
being recognizable on older software.

Regards,
Martin

Re: quote marks [was: Status of i18n patches]

[Zack Weinberg]

On Mon, Oct 14, 2002 at 08:27:34PM +0200, Martin v. Loewis wrote:
> Zack Weinberg <zack@codesourcery.com> writes:
> 
> > > One option: we could have the various error routines post-process
> > > the error message before printing.  Depending on an option or the
> > > locale it could either emit a pair of 0x27 or a 0x2018/0x2019 pair
> > > ...
> > 
> > An interesting idea... although, if we go with the double-quote
> > suggestion, it should be 0x201C/0x201D.  Don't recent versions of
> > gettext have the ability to recode messages on output?
> 
> glibc will do transliteration, translating 201C/201D with
> 0022. 2018/2019 transliterate to 0027. Dunno if standalone
> gettext/iconv can also transliterate.

I'm pretty sure glibc gettext/iconv are kept in sync with standalone.
They are, however, newer than what's in the gcc CVS.  Updating them is
on my list for 3.4, but has to be coordinated with binutils/gdb.

zw

Re: quote marks [was: Status of i18n patches]

[Gabriel Dos Reis]

Per Bothner <per@bothner.com> writes:

| While we're at it, perhaps it is time to fix things like:
| `%s' to '%s' - i.e. get rid of uses of 0x60 GRAVE ACCENT as
| "begin single quote". 

100% agreed.

-- Gaby