Re: [PATCH v2 01/11] i18n: add--interactive: mark strings for translation
- From
Jakub Narębski <jnareb@gmail.com>
- Date
- Sep 29, 2016, 21:21 UTC
- Message-ID
- <906445d8-25df-1b9a-8656-631ce007fc39@gmail.com>
- In-Reply-To
- <xmqqr387y4le.fsf@gitster.mtv.corp.google.com>
W dniu 26.09.2016 o 00:52, Junio C Hamano pisze:
> Vasco Almeida <vascomalmeida@sapo.pt> writes:
Show 8 quoted lines
>> my $status_fmt = '%12s %12s %s';
>> -my $status_head = sprintf($status_fmt, 'staged', 'unstaged', 'path');
>> +my $status_head = sprintf($status_fmt, __('staged'), __('unstaged'), __('path'));
>
> Wouldn't it make sense to allow translators to tweak $status_fmt if
> you are allowing the earlier elements that are formatted with %12s,
> as their translation may not fit within that width, in which case
> they may want to make these columns wider?Perl's printf, sprintf, and format think all codepoints take up 1 print column; also, without "use utf8;" they all think that one byte is one codepoint (as it is in latin1 encoding).
Many codepoints can take 0 print columns (zero-width joiners), or 2 columns (so called wide characters).
The proper way to justify Unicode output is described e.g. in http://www.perl.com/pub/2012/05/perlunicook-unicode-column-width-for-printing.html
use Unicode::GCString;
my $gcs = Unicode::GCString->new($str); # grapheme cluster string my $cols = $gcs->columns; my $pad = " " x (12 - $cols);
$status_head .= $str . $pad . " ";
Though we would need to provide fallback if there is no perl-i18n, no extended Unicode support in Perl (also, if we are not using gettext).
So it is even more complicated.
Show 12 quoted lines
>> prompt_yesno(
>> - 'Your edited hunk does not apply. Edit again '
>> - . '(saying "no" discards!) [y/n]? '
>> + # TRANSLATORS: do not translate [y/n]
>> + # The program will only accept that input
>> + # at this point.
>> + __('Your edited hunk does not apply. Edit again '
>> + . '(saying "no" discards!) [y/n]? ')
>
> Not just [y/n], but "no" in "saying no discards!" also needs to
> stay, no? I wonder if it is a good idea to lose the TRANSLATORS
> comment by ejecting "[y/n]" outside the "__()" construct here.Actually the message to translators should also mention that if the translation of "no" doesn't begin with 'n', then one needs to say something like '(saying "n" for "no" discards!)'.
Best,
-- Jakub Narębski