bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] 4-gary-version-etc-full-author-string.patch


From: Paul Eggert
Subject: Re: [Bug-gnulib] 4-gary-version-etc-full-author-string.patch
Date: 23 Sep 2003 16:50:11 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Bruno Haible <address@hidden> writes:

> I assume that by "higher-quality output" you mean a perfect line breaking.

Not really.  (Nobody's perfect.  :-)

>       1. you cannot say that "It's easily automated, using the same sorts
>          of tools that translators are already familiar with." - because
>          the translators are not commonly caring for line breaking.

That's up to them.  If they don't care about line breaking elsewhere,
then they don't need to care here.  These issues arise in many
strings, and translators can deal with them systematically themselves,
as they see fit.  I don't see much point to optimizing this little
corner of translations if there's a giant sea of line-breaking
problems elsewhare.

>          /* TRANSLATORS: You are welcome to insert line breaks here, to
>             limit each line's length to 80 columns.  But don't break the
>             line between the constiuents (first name and last name) of
>             a proper name.  */

Surely this sort of decision should be up to translators.

> By the way, we have hundreds of error messages with filenames or other strings
> that are substituted through printf. The translators do _not_ attempt to do
> line breaking.

Even in English, automatically-generated lines with user-supplied data
sometimes get too long.  It would be nice to address this issue, but
it's a somewhat-different issue.  With the "Written by" lines, the
issue doesn't arise, since they don't contain user-supplied data.

> By the way^2, g++ and SGI cc have line breaking in their error messages,
> and I find them harder to read than without line breaking

I tend to agree.  I wasn't proposing that.

> What are these "other good arguments"

Basically, what I've already said in this thread.  Obviously I haven't
convinced you.  (But I thought I had good arguments.  :-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]