nano-devel
[Top][All Lists]
Advanced

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

Re: [Nano-devel] Nano translation: 40 characters maximum in --help


From: Benno Schulenberg
Subject: Re: [Nano-devel] Nano translation: 40 characters maximum in --help
Date: Wed, 19 Sep 2018 21:17:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

Hello Mario,

Op 19-09-18 om 11:16 schreef Mario Blättermann:
> #: src/nano.c:792
> msgid "Convert typed tabs to spaces"
> msgstr "Eingegebebene Tabulatoren in Leerzeichen umwandeln"
> 
> This string (and not the only one) is almost impossible to shrink to
> 40 characters in German. I thought about a forced line break, but
> don't know if this would work:
> 
> #: src/nano.c:792
> msgid "Convert typed tabs to spaces"
> msgstr ""
> "Eingegebebene Tabulatoren in Leerzeichen\n"
> "  umwandeln"
> 
> I have to make sure that both lines stand one below the other, with an
> indention of two characters at the second and any following lines.
> Would this appear as expected?

No, unfortunately not.  You would have to precede the "umwandeln" with
five tabs plus two spaces to get the desired effect.  So, there is a
way to get what you want, but it is not obvious nor nice.

> BTW, Nano has an unusual way to present the help output to
> translators. Most other projects place the parameters and the
> associated descriptions in one string [...]
> 
> This is better for us, because we can place the needed whitespaces and
> see the effect immediately, as long as the editor is configured to use
> a Monospace font

I know.  It has been like this for a long time, and I haven't wanted
to change it, to avoid breaking all the existing translations.

Looking back in history, it was commit 3fc5d572 [1] that changed it
from your preferred style to the current one.  The reason is that nano
wants to cater both for systems with and systems without getopt_long()
-- in the past apparently the whole help text was duplicated in two
different versions: with and without the GNU long options.

(But nowadays we use gnulib, and getopt_long() will always be available
[2].  So the reason for the duplication is gone.  So in theory we could
go back to the "all in one string" style.)

[1] http://git.savannah.gnu.org/cgit/nano.git/commit/?id=3fc5d572
[2] http://git.savannah.gnu.org/cgit/nano.git/commit/?id=272345cc

Regards,

Benno

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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