Re: [sharutils] unwieldy msgids, unnecessary reformatting

[Benno Schulenberg]

(I've reincluded the list in the CC.)

On Thu, Jan 10, 2013, at 20:47, Bruce Korb wrote:
> On 01/09/13 09:18, Benno Schulenberg wrote:
> > In the recent releases of sharutils, the help-text fragments for
> > 'shar' first disappeared from the POT file, and then in the next
> > release reappeared as one giant text.
> 
> The disappearance was a mistake.  The reappearance was the result
> of not having good guidance on how to do it best.  Some years back,
> I solicited some help but didn't get a response.
> 
> With short fragments, it is easier to translate, but these short
> fragments get woven into usage text in ways that are disparaged
> by the docs I've read for i18n text.

With "fragment" I mean always a whole line, or a small group of
whole lines.  Where is this discouraged in i18n documents?

> Specifically, little bits
> of the usage are emitted with the expectation that a consistent
> amount of horizontal space is used.  That works IFF the source
> language is the display language.

When a certain indentation needs to be maintained, this is the
responsibility of the translator.  Half of the time I use a slightly
different indentation than the original, and use it consistently.

> My solution for this woven text problem is to build a version
> without a combined usage text, print the help with bit-at-a-time
> text and suck that output into a combined usage string and
> rebuild.  In the rebuild, the short strings will never be
> used.

In the source code I see for example:

    static char const shar_opt_strs[10449] =" [[[enormous string]]] ";

and afterward a hundred or so definitions like:

    #define INPUT_FILE_LIST_DESC      (shar_opt_strs+1777)

In my opinion this is madness...  If you want to add a space
or a word somewhere, you have to figure out and change fifty
indexes by hand... !


> But that is the cause of the next problem:
> 
> > Please also subdivide the printing of larger texts into several print
> > statements that each encompass a single paragraph.  It is much
> > easier for translators.  For example, the now 36-line help text
> 
> A possible solution for this is to fiddle the code so that it
> detects a localized environment and requests a paragraph at a time.
> I'd have to jigger something to split up the message the same
> way for the extraction code.  The gettext program extracts the
> text from uuencode-opts.c in a function bogus_function() that
> does not get compiled.  The actual string lives in a character
> array uuencode_opt_strs[4248] defined above.  I could also put
> it directly into a .pot file and bypass the text extraction.
> 
> Suggestions would be very, very welcome.  FYI, there are other
> projects that use AutoOpts, most notably NTP and GNUtls.
> But a simple, consistent way of getting it to work for all
> AutoOpts clients would be nice, and probably save i18n effort
> should any more of them get internationalized.

Is it AutoOpts that requires that the help text be provided as a
single huge character array?  Or do you need these indexes only
because you decided to use something like:

    static tOptDesc optDesc[OPTION_CT] = { [[[bunch of stuff]]] }


It all looks horribly complicated and intertwined to me.  Indexes
and lengths are something that the program should figure out,
not ever the programmer.


>   http://www.gnu.org/software/autogen/autoopts.html
> 
> > 'uuencode' contains near the end three pargraphs of running text,
> > which reoccur identically a bit further on as a separate text -- if
> > the text or its paragraphs had been gettextized separately, the
> > second occurrence wouldn't cost translators any extra work.
> 
> Since there is only one source for both texts, getting this to
> work depends upon coming up with a paragraph splitting algorithm
> that would split out an exactly matching paragraph.  A desirable
> goal, but might not be easy to do.  Please suggest an algorithm
> while I try to puzzle one out, too.  (e.g. separate on every
> double newline and every line starting with white space.
> Does that yield something more usable?)

_If the help text needs to be a single huge string, why not "add"
(concatenate) many small gettexttized strings?  Something like:

    hugestring = _("shar (GNU sharutils) 4.13.3\n")
    + _("Copyright (C) 1994-2013 Free Software Foundation, Inc., all rights 
reserved.\n")
    + _("This is free software. It is licensed for use, modification and\n")
    + ...

I have no idea how to actually do this, but it should be possible,
and then let the program itself work out what the lengths of all
these substrings are (_if you actually need the indexes).

Benno

> > (I would provide a patch, but it would be so huge you probably
> > wouldn't be allowed to accept it without a copyright assignment.)
> 
> Thank you for considering it, but as you have gathered by now,
> any patch to bogus_function() would not be very useful.
> 
> > (Also, there are several typos in some of the new msgids, for example
> > "create a shell archiv", but that is a minor issue compared to the
> > reformatting of the strings into enormous texts.)
> 
> I have to figure out when I need to delete the last character and
> when not, and then adjust some Scheme code to do it correctly.
> 
> Thank you for your well considered response!  Regards, Bruce

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