Subject: Re: [PATCH v2 1/2] object.[ch]: mark object type names for translation

From: Junio C Hamano <[email-masked]>
Date: Wed, 06 Oct 2021 12:46:12 -0700

Jeff King <[email-masked]> writes:

> They all appear to want is as a noun. So maybe this is just
> mis-translated for Spanish. It does feel like an accident in the making,
> though.

Probably we need pgettext().

https://www.gnu.org/software/gettext/manual/html_node/Contexts.html

> I do wonder how useful it is to translate these type names in general.
> Especially as used in this series, they're really technical terms, and
> you are not going to escape the name "git commit" as a command.

I share the same feeling (I do not use translated git, either).

> Now if you introduced type_name_human(), which auto-translated and
> converted NULL to "unknown", then that would be easy to plug in
> appropriately as you audited the callers.

Yes.

>
>>  static const char *object_type_strings[] = {
>> ...
>> +	N_("commit"),	/* OBJ_COMMIT = 1 */
>> +	N_("tree"),	/* OBJ_TREE = 2 */
>> +	N_("blob"),	/* OBJ_BLOB = 3 */
>> +	N_("tag"),	/* OBJ_TAG = 4 */
>>  };
>
> This does make me feel slightly uneasy, just because so many parts of
> Git rely on these _not_ being translated. But I see in your other
> response that N_() really does nothing. So aside from possibly
> misleading readers of the code, I think this is probably OK.

Yes, this may be scary looking but the least risky part of this
patch, as N_() is no-op at runtime ;-).