On Thu, Jul 11, 2013 at 12:50 PM, Eric Sunshine <sunsh...@sunshineco.com> wrote:
>>> +       maybe_flush_or_die(stdout, "contact to stdout");
>> On error this function will print
>> write failure on 'contact to stdout'
>> maybe maybe_flush_or_die(stdout, "write contact to stdout") or
>> something? From i18n point of view, maybe_flush_or_die should not
>> compose a sentence this way. Let the second argument be a complete
>> sentence so that translators have more freedom. But that's a different
>> issue.
> Indeed, it's not ideal. I chose "contact to stdout" for consistency
> with other callers, not because of a fondness for it.
>   % git grep maybe_flush_or_die
>   builtin/blame.c: maybe_flush_or_die(stdout, "stdout");
>   builtin/check-attr.c: maybe_flush_or_die(stdout, "attribute to stdout");
>   builtin/check-attr.c: maybe_flush_or_die(stdout, "attribute to stdout");
>   builtin/check-ignore.c: maybe_flush_or_die(stdout, "check-ignore to 
> stdout");
>   builtin/check-ignore.c: maybe_flush_or_die(stdout, "ignore to stdout");
>   builtin/hash-object.c: maybe_flush_or_die(stdout, "hash to stdout");
>   builtin/rev-list.c: maybe_flush_or_die(stdout, "stdout");
>   log-tree.c: maybe_flush_or_die(stdout, "stdout");
> They seem pretty evenly split between just "stdout" and "foo to
> stdout". (I actually prefer plain "stdout" and will happily change it
> to that.)

Then probably stick to the convention. If this i18n thing is fixed, it
has to be fixed everywhere anyway.
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