Re: [sharutils] unwieldy msgids, unnecessary reformatting

[Benno Schulenberg]

Hi Bruce,

On Sun, Jan 13, 2013, at 23:07, Bruce Korb wrote:
> I omitted the entire list because I'm expecting a somewhat boring
> discussion.  I'd be more interested in translator feedback, because
> you-all are more directly affected.

It may be boring, but one never knows whether not someone else
has some good idea on how to handle this.  And it is good to have
the discussion archived somewhere.

> The "short fragments" are the long option names and the short
> (~40 character) description, [...]
>
> the option line in long usage appears as:
>    -g, --level-of-compression=num pass LEVEL for compression
> That string does not appear anywhere in the source.
> It gets pulled together and formatted from the "g", "level-of-compression",
> "number", "1->9" and "pass @file{LEVEL} for compression" strings.
> So in order to make something that is translatable, I create
> a program, emit the help, capture that help text and
> put it into the final program.

Alright, now I understand.  Indeed it is not good to offer those
fragments for translation, but it would be perfectly okay to offer
each complete option description, for example the above:

  "-g, --level-of-compression=num pass LEVEL for compression"

> AutoOpts only requires the strings associated with each option and
> the program as a whole.  On the theory that gluing all these strings
> together would be untranslatable and/or sometimes not yield an
> aesthetically pleasing help string, I provided a way of overriding
> the computation of the usage text by providing _as an alternative_
> the entire usage text as a single string.  What I am proposing here
> is emitting this long usage a paragraph at a time.

Paragraphs are good, whole sentences are good, a complete option
plus its description (like the above) is good, a full doc string is good,
an entire usage summary is good -- anything that is self-contained
and doesn't break a sentence is good.

> The pieces of the help text are derived from too many sources.
> Gluing together little strings is strongly discouraged for
> translatable text.  Therefore, I am suggesting the splitting up
> of the monster string according to a well defined algorithm.
> viz. start  a new "paragraph" whenever a non-empty line is
> preceded by two line breaks or a non-empty line starts with
> a few space characters.  I *think* that yields something wieldy.

If you split off non-empty lines that start with some whitespace,
you would fragment multiline option descriptions.  That is not good.
Some examples of which text fragments I would like to see:

N_("Specifying file encoding methodology:\n")

N_("   -M, --mixed-uuencode       decide uuencoding for each file\n")

N_("   -B, --uuencode             treat all files as binary\n"
"                                - an alternate for mixed-uuencode\n")

N_("   -T, --text-files           treat all files as text\n"
"                                - an alternate for mixed-uuencode\n")

N_("Options are specified by doubled hyphens and their name or by a single\n"
"hyphen and the flag character.\n")

N_("If no 'file's are specified, the list of input files is read from a\n"
"standard input.  Standard input must not be a terminal.\n")

((By the way, this "- an alternate for mixed-uuencode" phrase is unneeded,
in my opinion.  A help text should be concise, and that these options are
alternates is already clear by grouping them under the same heading.))

> I could also split them one string per line.  That is likely
> somewhat easier for me, but seems like it would make the
> translation task a bit harder.  e.g. there would be no guarantee
> that every line would be unique and the same line of text might
> translate differently in different contexts.

One string per line will be fine, as long as it does not split up sentences.
What would be best: the smallest elements that you can make that are
self-contained.

Regards,

Benno

-- 
http://www.fastmail.fm - Access all of your messages and folders
                          wherever you are