Thread (1 message) 1 message, 1 author, 2017-05-04

Re: [PATCH] i18n: remove i18n from tag reflog message

From: Junio C Hamano <hidden>
Date: 2017-05-04 01:35:24

Jean-Noël AVILA [off-list ref] writes:
Le dimanche 30 avril 2017, 18:45:05 CEST Junio C Hamano a écrit :
quoted
Jean-Noel Avila [off-list ref] writes:
quoted
The building of the reflog message is using strbuf, which is not
friendly with internationalization frameworks. No other reflog
messages are translated right now and switching all the messages to
i18n would require a major rework of the way the messages are built.
Thanks for spotting.  Before we declare that reflog messages are for
i18n, we'd need to either drop (or redesign the implementation of)
the "checkout -" feature, which relies on the exact phrasing of how
reflog entries from "git checkout" looks like.

Will queue and merge down to 'master' quickly.
I didn't know this "side effect". Maybe adding a test against it would be 
requiered. Unfortunately, I don't know enough of it.
Sorry, but I am not sure what "side effect" you are referring to.  I
am saying that in the current codebase not translating tag reflog
message (i.e. your fix) is the right thing to do.

builtin/checkout.c does

		strbuf_addf(&msg, "checkout: moving from %s to %s",
			old_desc ? old_desc : "(invalid)", new->name);

when "git checkout" is used to switch from old to new branch.  The
above phrasing is used by sha1_name.c::grab_nth_branch_switch() to
know what branch you were on, and not having _() around the message
is the right thing to do, at least in the current codebase.

If somebody wants to i18n the reflog message, that needs to be done
at the reading/dispaying end, I would think.  Instead of being purely
textual records, a new reflog format would have to be a machine
parsable message-id with parameters, and the code that wants to
understand the reflog record like grab_nth_branch_switch(), as
opposed to show the record to the humans, would just use the machine
parsable raw data, while "git reflog" and friends that format the
reflog record would give the message-id to gettext and feed the
parameters recorded using the result of gettext() as the format
string to fprintf(), or something like that.




Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help