bug-bash
[Top][All Lists]
Advanced

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

Re: gettextizing a few skipped messages [patch]


From: Benno Schulenberg
Subject: Re: gettextizing a few skipped messages [patch]
Date: Sat, 25 Nov 2006 19:59:03 +0100
User-agent: KMail/1.9.5

Chet Ramey wrote:
> Benno Schulenberg wrote:
> > On the other hand, it looks like all of the message strings in
> > lib/malloc/watch.c are debugging messages, [...]
>
> Yes.  The affected code is not compiled in by default unless
> DEBUG is defined, and that has to be turned on manually when the
> shell's release status is `release'.  Presumably anyone who does
> this (primarily me :-) ) is able to deal with the untranslated
> messages.

So you will ungettextize them, to lighten the burden on the 
translators just a little?

> > In many short doc strings the case of the parameters in the
> > first line does not match the case in the rest of the
> > explanation.  [...]
>
> This is intentional.  The completely-capitalized words in the
> body of the documentation string are intended to be a sort of
> meta- notation.

But then, to be consistent, some other parameters will have to be 
lowercased too.  For example:

  caller [EXPR]
  for NAME [in WORDS ... ;] do COMMANDS; done
  for (( exp1; exp2; exp3 )); do COMMANDS; done
  select NAME [in WORDS ... ;] do COMMANDS; done
  time [-p] PIPELINE
  case WORD in [PATTERN [| PATTERN]...) COMMANDS ;;]... esac
  while COMMANDS; do COMMANDS; done

In my opinion, however, it's much clearer to have the fixed parts in 
lower case and the replaceables in uppercase -- at least for these 
help messages that cannot use anything like bold, underline, italics 
or colours.

> texinfo does the same thing when rendering 
> @var{name} for ttys, though it uses quotes.

But it renders @var{dir} as `DIR' also in the short description, not 
only in its explanation.  See for example 'info bash bash the dir'.

In all synopses in the info pages uppercasing is used in the way I'd 
like to see it used in the help messages too.  In the man page this 
isn't done, and it results in some quite confusing synopses:

       popd [-n] [+n] [-n]

       pushd [-n] [dir]
       pushd [-n] [+n] [-n]
 
On the console there's no difference to be seen between the first 
'-n' and the second.  And to make matters worse, the second '-n' is 
described first, and the first second.  In an xterm or Konsole this 
is slightly less of a problem as options are bold and parameters 
underlined.  But still, to alleviate the confusion a little, at 
least the arguments should be described in the order that they 
appear in the synopsis.  See the first patch for the man page.  The 
second patch does the same for the info page, and also puts options 
before other arguments, adds two blank lines, removes a short 
superfluous sentence, and fixes an incorrect 'cd DIR'.

> > Much better than just that would be: if also the first line of
> > the short doc string were gettextized (like they used to be in
> > older versions of bash), [...]
>
> This is a good idea; I will make the change.

Thanks.  Just to make sure there isn't any misunderstanding: you 
will gettextize the synopsis of each builtin command as a separate 
string, and not as a part of its explanation?  Because the latter 
would make the Spanish and Turkish translators (and me too) pretty 
unhappy, rendering most of their work useless for the next release.

> > with the superfluous
> > "N_(...)" lines removed from caller.def and pushd.def.  [...]
>
> These builtins can be compiled
> as part of the shell or as loadable builtins.  When compiled as
> loadables, they are not processed by mkbuiltins, and the long
> documentation strings don't end up in builtins.c,

But when bash is compiled with --disable-directory-stack, the 
strings that belong to dirs/pushd/popd still end up in the bash.mo 
files, both the long strings _and the chopped up ones -- simply 
because bash.pot is made at release time, not compile time.

I don't understand how to compile pushd and friends as separately 
loadable things (./configure --help doesn't say anything about it), 
otherwise I would have tested it to see if they get translated 
anyway.

> so they have to 
> be marked as translatable somehow.

If this duplication of strings is nevertheless necessary, then 
please mark each message in its entirety, not line by line.  If 
that somehow is not possible, then please add comments to warn 
translators that these strings are superfluous.  See third patch.  
Gettext will copy these comments automagically to bash.pot and the 
po files.

Benno

Attachment: bash-manpage-parameter-order.patch
Description: Text Data

Attachment: bash-infopage-parameter-order-2.patch
Description: Text Data

Attachment: bash-translator-comments.patch
Description: Text Data


reply via email to

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