On Thu, Jul 11, 2013 at 12:50 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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. -- Duy -- 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