[PATCH 2 of 2] subrepo: make the '(in subrepo %s)' hint more translation friendly

Laurens Holst laurens.nospam at grauw.nl
Tue Jan 8 17:18:44 UTC 2013


Op 08-01-13 17:43, Angel Ezquerra schreef:
> On Tue, Jan 8, 2013 at 5:16 PM, Laurens Holst <laurens.nospam at grauw.nl> wrote:
>> Op 03-01-13 18:17, Angel Ezquerra schreef:
>>
>>> # HG changeset patch
>>> # User Angel Ezquerra <angel.ezquerra at gmail.com>
>>> # Date 1357231345 -3600
>>> # Node ID 58dd1c9df93299eb2fd80292419998e078968e04
>>> # Parent  5a1a5555319c13de73e51d271de5356b4a0656d0
>>> subrepo: make the '(in subrepo %s)' hint more translation friendly
>>
>> Hmm, how do you mean, more translation friendly?
>>
>> You just removed the ability for translators to juggle the sentence order...
> Actually that is not true. If they juggled the sentence order they
> would get the wrong message, since the message is used on a
> "printf-like" expression that forces the 1st "%s" to be the error
> message and the second to be the subrepo path.
>
> Thus, this patch makes sure that it is not possible for a translator
> to make a mistake and mistakenly invert the order of the "%s" strings,
> which would not work.

Ah, of course, yes :).

(At work we include indices in our localisable string formatting, e.g. 
%1s :).)

> However that is not the true, main purpose of this patch... (see below)
>
>>> This patch makes the '(in subrepo %s)' hint that is printed when a subrepo
>>> throws an error a bit easier to use tools that must parse mercurial's
>>> output,
>>> such as GUI tools (e.g. TortoiseHg).
>>
>> Sounds like you really mean it is making the hint more automation-friendly?
>>
>> (Though I don’t see how it does? Output remains the same, doesn’t it?)
>>
>> ~Laurens
> I mean both, although I understand how you could see it your way.
>
> The patch is meant to make it easier for tools that wrap the mercurial
> output to find the "in subrepo" string at the end of the error
> message.
>
> In that sense the patch does make the message more "automation"
> friendly, but it also makes it easier for tools such a TortoiseHg to
> work well when the mercurial output is translated, because it makes it
> easier for them to look for "in subrepo" references regardless of the
> output language (hence the "more translation friendly" commit
> message).
>
> Case in point:
>
> The next version of TortoiseHg will look for these "in subrepo"
> messages and turn them into links that, when clicked, will open the
> corresponding subrepo on the corresponding revision.
>
> Currently there is no simple, reliable way for TortoiseHg to look for
> those "in subrepo" messages in Mercurial's output, precisely because a
> translator might potentially place the "in subrepo" part before the
> actual error message. In addition it is not possible for TortoiseHg to
> know which string it should look for because "%s (in subrepo %s)"
> could be translated into anything. However, if mercurial had an "(in
> subrepo %s)" i18n string, mercurial could just get that translated
> string and look for it. We could do some hacky tricks (e.g. replacing
> "%s" with'') but they are, well, hacky.
>
> That is why, without this patch (and the previous one), the
> "linkification" of subrepo references will only happen, in TortoiseHg,
> when the language is set to English, which I hope to fix.
>
> I hope I've been able to explain what I meant. Do you think that I
> should resend the patch or do you think it is ok in light of this
> explanation?

Thanks for your elaborate explanation. I think it also nicely explains 
why you would be trying to parse localised text in the first place 
(answer: to decorate it with a link).

I think you should put some of this into the patch description. (Perhaps 
in place of the last sentence which just repeats in words what the patch 
itselfalready shows.)

~Laurens




More information about the Mercurial-devel mailing list