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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Oct 5, 2021, 15:52 UTC
Message-ID: <874k9vlawx.fsf@evledraar.gmail.com>
In-Reply-To: <5d47caad-7f0b-f6ce-b055-dc21d58892cc@gmail.com>

On Tue, Oct 05 2021, Bagas Sanjaya wrote:

Show 26 quoted lines

> On 04/10/21 21.27, Ævar Arnfjörð Bjarmason wrote:
>>   static const char *object_type_strings[] = {
>>   	NULL,		/* OBJ_NONE = 0 */
>> -	"commit",	/* OBJ_COMMIT = 1 */
>> -	"tree",		/* OBJ_TREE = 2 */
>> -	"blob",		/* OBJ_BLOB = 3 */
>> -	"tag",		/* OBJ_TAG = 4 */
>> +	/*
>> +	 * TRANSLATORS: "commit", "tree", "blob" and "tag" are the
>> +	 * name of Git's object types. These names are interpolated
>> +	 * stand-alone when doing so is unambiguous for translation
>> +	 * and doesn't require extra context. E.g. as part of an
>> +	 * already-translated string that needs to have a type name
>> +	 * quoted verbatim, or the short description of a command-line
>> +	 * option expecting a given type.
>> +	 */
>> +	N_("commit"),	/* OBJ_COMMIT = 1 */
>> +	N_("tree"),	/* OBJ_TREE = 2 */
>> +	N_("blob"),	/* OBJ_BLOB = 3 */
>> +	N_("tag"),	/* OBJ_TAG = 4 */
>>   };
>>   
>
> Are these object type names safe for translating? (e.g. can they be
> translatable without affecting private API string, which aren't 
> translatable)?

Yes, the N_() macro is always a noop. It's just there so the i18n tooling knows to pick up these strings and drop them into po/git.pot. See po/README.md for details.

It does change the behavior of any code that later does _(type_name(type)), as the string will then (potentially) be found in the *.mo files, but as shown in 2/2 that needs to be added to each callsite manually. So we're not going to translate "ls-tree" output or whatever just because it has "tree" etc. in it.

Show 13 quoted lines

>> +/*
>> + * TRANSLATORS: This is the short type name of an object that's not
>> + * one of Git's known object types, as opposed to "commit", "tree",
>> + * "blob" and "tag" above.
>> + *
>> + * A user is unlikely to ever encounter these, but they can be
>> + * manually created with "git hash-object --literally".
>> + */
>> +const char *unknown_type = N_("unknown type");
>> +
>>   const char *type_name(unsigned int type)
>
> Did you mean that "unknown type" is generic shorthand?

Yes, we could get the actual type name here, but it's a bit of a pain, and as noted in 2/2 this code doesn't work anyway (which pre-dates this series).

But I'll see if I'll remember to loop around to fixing it after my fsck/object library fixes related to this land, but for now just marking this for translation makes senes I think.