i18n and accuracy (was Re: [PATCH] annotate: print revision...)

Wagner Bruna wagner.bruna+mercurial at gmail.com
Thu Mar 4 09:20:25 CST 2010


Matt Mackall wrote:
> Martin Geisler wrote:
>> Wagner Bruna writes:
>>
>> So far our policy has been to be unprofessional about this and
>> just make string changes at will, even close to a release... But
>> I agree with Wagner that it would be better to postpone such
>> changes.
> 
> Folks, I've said no to "string freezes" several times and that's
> because I strongly feel that having accurate untranslated strings
> is better than having inaccurate but translated strings.

I agree - for completely wrong or misleading messages, or for users 
that can understand simple English. But for users who can't, an 
understandable-but-inaccurate message is far better than a message 
they can't understand at all. In this specific case, those users would 
get "huh, what is this command supposed to do?" instead of "funny, the 
help didn't mention the revision number for this option".

The main problem is with big help texts, since a small change like 
this invalidates the whole translation. Splitting the messages on 
paragraph boundaries before translating would probably help a lot 
here: the user would get an English paragraph instead of an English 
page (like what happens with option messages). I intend to make such a 
change for 1.6.

> It's that simple. We don't hold back bug fixes and we doc fixes.
> If that means that 1.x is always slightly less completely
> translated than 1.x.1, I don't feel that's a significant issue.

But if I understand it correctly, the freeze policy just before 1.x is 
exactly the same as just before 1.x.y, isn't it? So 1.x.1 may actually 
have less translations than 1.x.

Thanks,
Wagner

> One day, when Mercurial development gets boring, I may reconsider.
> 
> That said, we should of course avoid truly gratuitous string
> churn during the freeze. Please try to stick to things that
> are clearly fixes, especially near the end.
> 
> [oh, and yes, I'm back. I expect to be quite busy tomorrow..]



More information about the Mercurial-devel mailing list