Jakub Narębski <jna...@gmail.com> writes:
> W dniu 29.09.2016 o 19:05, Junio C Hamano pisze:
>> Vasco Almeida <vascomalme...@sapo.pt> writes:
>>
>>> On the other hand, would it make sense to translate these commands? If
>>> so, we would mark for translation the commands name of @cmd in
>>> main_loop().
>>>
>>> sub main_loop {
>>> - my @cmd = ([ 'status', \&status_cmd, ],
>>> - [ 'update', \&update_cmd, ],
>>> - [ 'revert', \&revert_cmd, ],
>>> - [ 'add untracked', \&add_untracked_cmd, ],
>>> - [ 'patch', \&patch_update_cmd, ],
>>> - [ 'diff', \&diff_cmd, ],
>>> - [ 'quit', \&quit_cmd, ],
>>> - [ 'help', \&help_cmd, ],
>>> + my @cmd = ([ __('status'), \&status_cmd, ],
>>> + [ __('update'), \&update_cmd, ],
>>> + [ __('revert'), \&revert_cmd, ],
>>> + [ __('add untracked'), \&add_untracked_cmd, ],
>>> + [ __('patch'), \&patch_update_cmd, ],
>>> + [ __('diff'), \&diff_cmd, ],
>>> + [ __('quit'), \&quit_cmd, ],
>>> + [ __('help'), \&help_cmd, ],
>>
>> I don't know offhand. If the code to prompt and accept the command
>> given by the user can take the translated word (or a prefix of it),
>> theoretically I would say it could be made to work, but to me it is
>> dubious the benefit outweighs its downsides. It would make teaching
>> Git and troubleshooting over the phone harder, I would guess.
>>
>> A: "Hi, I am in a 'git add -i' session."
>> B: "Give 's' at the prompt."
>> A: "My Git does not seem to take 's' as a valid command."
>> B: "What? I've never seen that problem."
>> ... back and forth wastes 10 minutes ...
>> A: "By the way, I am running Git in Portuguese."
>
> Also, for one-letter commands to work (there is setting where you
> don't even need to press enter, IIRC) all those translations would
> have to be chosen to begin with different letter, isn't it?
The original was written with an explicit expectation that these
command words will not be translated adn chose words that do not
share the first letter exactly for that reason.
Having said that, if somebody is willing to i18n the command words,
I'd expect that the command line prompt interaction would be updated
to take the unique prefix instead of the "first byte", and if that
happens, I think the resulting system would at least be internally
consistent.
It is still dubious to me if the benefit of i18n outweighs its
downsides, though.
