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

[Bruno Haible]

Paul Eggert wrote:
> > It will not be optimal, certainly. But I think it's bearable.
>
> I guess we have different tradeoffs.  I'd rather have the solution
> that generates higher-quality output in general,

I assume that by "higher-quality output" you mean a perfect line breaking.
Where shall this perfect line breaking come from?

  - According to your proposition, the translator must provide it. But
    then
      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.
      2. you must tell the translators how to do the line breaking. So add
         this comment in front of each of the "Written by..." strings. 90
         times.

         /* 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.  */

  - If it does not come from the translator, then it must be done through
    some code in the executable. If you link the code directly, it becomes
    big. If you pipe() through an internationalized version of "fmt" it
    becomes fragile...

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. For example:

  #, c-format
  msgid ""
  "In the directive number %u, the substring \"%s\" is not a valid date/time "
  "style."
  msgstr ""
  "In der %u. Formatanweisung ist die Unterzeichenkette »%s« kein gültiger "
  "Datums- bzw. Zeitstil."

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 - because their
line breaking algorithm assumes that every space is an equally good
opportunity. So what you consider higher quality can easily turn into
inferior quality if done badly. That's why you need to tell the translators
how to do it (item 2 above).

> particularly when
> there are other good arguments for doing it that way.

What are these "other good arguments" in favour of leaving all the work to
the translators?

Bruno