Re: [sharutils] unwieldy msgids, unnecessary reformatting

[Bruce Korb]

On 01/14/13 03:07, Benno Schulenberg wrote:
> 
> Hi Bruce,
> 
> On Sun, Jan 13, 2013, at 23:07, Bruce Korb wrote:
>> the option line in long usage appears as:
>>    -g, --level-of-compression=num pass LEVEL for compression

> 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:

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

Exactly my intention, actually.  A line starting with more than 8 spaces
would be considered an extension of the previous "hanging indent" line.

> ((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 agree and disagree both, without a strong commitment to either.
Let's pick up on that later, since that is not strictly speaking
a translation issue, but rather a "what makes sense" issue.

One other potentially translatable piece of text is the long option name.
I know that no other programs translate them, but it turns out to be
trivial to do so.  So in C locale:

   my-prog --first-option

could be used thus (in Spanish, my second language):

   my-prog --opcion-primero

my AutoOpts code doesn't care because it just looks up whatever bytes
appear after the double hyphen and before any '=' character.  That
does present problems with languages that embed the 0x3D character in
their representations, but certainly all the Roman alphabet based
languages *could* have their long options localized.  I've already
implemented the capability, so my question boils down to:

   Is it too far over the top?  :)

Thank you - Bruce