On Sun, Oct 11, 2015 at 9:42 PM, Matthieu Moy
<matthieu....@grenoble-inp.fr> wrote:
> Karthik Nayak <karthik....@gmail.com> writes:
>
>> On Fri, Oct 9, 2015 at 12:10 AM, Matthieu Moy
>> <matthieu....@grenoble-inp.fr> wrote:
>>> Karthik Nayak <karthik....@gmail.com> writes:
>>>
>>>> --- a/ref-filter.c
>>>> +++ b/ref-filter.c
>>>> @@ -1118,8 +1118,10 @@ static void populate_value(struct ref_array_item 
>>>> *ref)
>>>>                               char buf[40];
>>>>
>>>>                               if (stat_tracking_info(branch, &num_ours,
>>>> -                                                    &num_theirs, NULL))
>>>> +                                                    &num_theirs, NULL)) {
>>>> +                                     v->s = "[gone]";
>>>
>>> My remark about translation still holds. The string was previously
>>> translated in "branch" and you are removing this translation (well, not
>>> here, but when 09/10 starts using this code).
>>>
>>
>> I should have mentioned in my cover letter, I didn't really understand
>> what has to be done about this, couldn't find much reference to go
>> about this. What do you suggest?
>
> From the user point of view :
>
> git for-each-ref --format '%(upstream:track)' => Should always be the
> same, because this may be parsed by scripts (plumbing). Should not
> depend on $LANG, and shouldn't change from a version of Git to another.
>

A little blurry on how this works, as in how translation takes place,
probably need to look at some code.

> git branch --format '%(upstream:track)' => Should show what is most
> pleasant to the user (porcelain): translated according to $LANG and
> friends, and may be improved in the future.
>
> I already pointed out a fix where a string was translated in a plumbing
> command. Another example is setup_unpack_trees_porcelain() in
> unpack-trees.c which solves exactly the same problem.
>

You did. I was just too clueless.

> I'll followup with a small series on top of yours to show the way. I did
> not try to polish it since I guess you have local changes on the same
> part of the code. Feel free to squash patches together or to squash them
> with yours. The commit messages are not meant to be final either.
>

Thanks a lot for this. This should help me out. I'll probably squash them along.
Thanks :)

-- 
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to