A Dom, 25-09-2016 às 15:52 -0700, Junio C Hamano escreveu:
> > @@ -252,7 +253,7 @@ sub list_untracked {
> > }
> >
> > 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?
As far as I understand, %12s means that the argument printed will have
a minimum length of 12 columns. So if the translation of 'stage' is
longer than 12 it will be printed fully no matter what. Though in that
case, the header will not be align correctly anymore:
my $status_fmt = '%12s %12s %s';
123456789abcdefghijkl unstaged caminho
1: unchanged +1/-0 git-add--interactive.perl
2: unchanged +4226/-3152 po/git.pot
3: unchanged +11542/-10426 po/pt_PT.po
my $status_fmt = '%12s %8s %s';
123456789abcdefghijkl unstaged caminho
1: unchanged +2/-1 git-add--interactive.perl
2: unchanged +4226/-3152 po/git.pot
3: unchanged +11542/-10426 po/pt_PT.po
For reference in C locale (my $status_fmt = '%12s %12s %s';)
staged unstaged path
1: +4/-4 nothing git-add--interactive.perl
2: unchanged +4232/-3150 po/git.pot
3: unchanged +11572/-10448 po/pt_PT.po
I did not contemplate this issue before, but I think allowing a
translator to tweak $status_fmt would not be enough to properly align
the header if the translation is longer than 12 columns.
Maybe a lazy solution would be to add a TRANSLATOR: comment asking to
fit the translation of those words in 12 columns, but that would be
unpractical because 'stage' and 'unstage' can occur alone, like they do
here, in other place in the future, without having that length
restriction.
I think the real fix would be to find the longer column and use that
length for the remaining rows. I will try to do that if I can.
I also forgot to mark strings 'unchanged' and 'nothing' that are
displayed on that status. I will mark then in the next re-roll.
> > 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.
I fear that ejecting "[y/n]" would not be good for right-to-left
languages since "[y/n]" would be the first thing a user of those
languages would read followed by the actual question. I feel the same
for other instances of this in the present patch series.