[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
bash-manpage-parameter-order.patch
Description: Text Data
bash-infopage-parameter-order-2.patch
Description: Text Data
bash-translator-comments.patch
Description: Text Data