Re: [PATCH 06/25] gettextize: git-fetch formatting messages

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

 



On Thu, Sep 2, 2010 at 19:59, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> (+cc: some fetch ui authors, just as a heads up)
>
> Ævar Arnfjörð Bjarmason wrote:
>
>> --- a/builtin/fetch.c
>> +++ b/builtin/fetch.c
>> @@ -236,7 +236,7 @@ static int update_local_ref(struct ref *ref,
>>       if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
>>               if (verbosity > 0)
>>                       sprintf(display, "= %-*s %-*s -> %s", TRANSPORT_SUMMARY_WIDTH,
>> -                             "[up to date]", REFCOL_WIDTH, remote,
>> +                             _("[up to date]"), REFCOL_WIDTH, remote,
>>                               pretty_ref);
>
> Longer-term question: do people like to translate this kind of thing
> (with the arrows and so on) differently for right-to-left languages or
> is that considered overkill?

They do, on a RTL language the arrows are pointing the wrong way
round. But for now I'm not trying to solve RTL issues (or indeed, word
order or plural issues), just getting something basic going.

>> @@ -249,8 +249,8 @@ static int update_local_ref(struct ref *ref,
>>                * If this is the head, and it's not okay to update
>>                * the head, and the old value of the head isn't empty...
>>                */
>> -             sprintf(display, "! %-*s %-*s -> %s  (can't fetch in current branch)",
>> -                     TRANSPORT_SUMMARY_WIDTH, "[rejected]", REFCOL_WIDTH, remote,
>> +             sprintf(display, _("! %-*s %-*s -> %s  (can't fetch in current branch)"),
>> +                     TRANSPORT_SUMMARY_WIDTH, _("[rejected]"), REFCOL_WIDTH, remote,
>
> Regardless of the answer, we should probably be either consistently
> translating or not translating it within this patch.  e.g. for not
> translating (though I suspect translating is the better choice):

I added a _() there because there's English language text in the
message. I wouldn't have marked it if it was just "! %-*s %-*s -> %s".

And I haven't split up "! %-*s %-*s -> %s" and " (can't fetch in
current branch)" because I'm trying to make minimal changes so that
this can get through in a timely manner, before I have a mountain of
merge conflicts on my hands.

But yeah, we want to fix that in the future.

>                sprintf(display, "! %-*s %-*s -> %s  %s",
>                        TRANSPORT_SUMMARY_WIDTH, "[rejected]", REFCOL_WIDTH, remote,
>                        pretty_ref, _("(can't fetch in current branch)"));
>
>> @@ -260,8 +260,8 @@ static int update_local_ref(struct ref *ref,
>>               int r;
>>               r = s_update_ref("updating tag", ref, 0);
>>               sprintf(display, "%c %-*s %-*s -> %s%s", r ? '!' : '-',
>> -                     TRANSPORT_SUMMARY_WIDTH, "[tag update]", REFCOL_WIDTH, remote,
>> -                     pretty_ref, r ? "  (unable to update local ref)" : "");
>> +                     TRANSPORT_SUMMARY_WIDTH, _("[tag update]"), REFCOL_WIDTH, remote,
>> +                     pretty_ref, r ? _("  (unable to update local ref)") : "");
>
> Maybe we could stick to "%c %-*s %-*s -> %s%s", to make consistent
> translation easier.

Yeah, maybe. That's pretty much the only part of this series that
deals with issues like that. So it's probably worth a fixup.

(I.e. ignore what I said earlier :)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]