Re: [PATCH 1/1] Mark messages for translations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



And again, sigh:
>>   const char git_usage_string[] =
....
>>   const char git_more_info_string[] =
> It is not obvious to me where git_usage_string is looked up in the
> message catalog. It is used that way in builtin/help.c ..

I wanted to be consistent with the current state of the file. This is the
same way const char git_more_info_string[] is defined and initialized.
Having it this way saves the lookup on each usage I guess but any performance
gains will be negligible. Is there a convention?

> We have settled with lower-case letters at the beginning of error
> messages. (See Documentation/CodingGuidelines, "Error Messages".) You
> could fix that while you are touching die, die_errno, etc, messages.

Great! It will allow for further reduction in repetition of messages.

> I notice you change past tense to present tense in some cases.
I am reading this that messages SHOULD be in present tense (unless they MUST
be in past tense). This is good. Perhaps I will look at current messages and
then fix en masse (if there is sth to fix).

> I'm not a friend of geeky abbreviations like "chdir" or "cwd" in
> user-visible messages

I agree but I would also keep in mind that using the name of the function
may alllow to parametrize the messages like:
Cannot execute "%s" on "%s" - for example. Anyway this is not that important
for me. Will wait for other opinions.

>> -                     die_errno("fork failed");
>> +                     die_errno(_("fork failed"));
>> -             die_errno("setsid failed");
>> +             die_errno(_("setsid failed"));

> it is useful to have the function name in  the message. Which rises the
> question:why translate them at all?
Why not eat the cake while having it - one can pass function name in  a
 message like: '"%s" failed'

Regards:
al_shopov



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux