[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: One line patch for Korean translation (ko.po)

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Tue, 05 Aug 2008 12:05:10 -0400

Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
> Jens Seidel wrote on Sat, 26 Jul 2008 at 15:20 +0200:
> There is a rule that says you shouldn't commit a change just because you
> think it's likely to be correct. HACKING says:
> Voting +1 on a change doesn't just mean you approve of it in principle.
> It means you have thoroughly reviewed the change, and find it correct
> and as nondisruptive as possible.

I think that's about code changes, and possibly during release
preparation too.

Obviously, it would be ideal if every translation line got checked by at
least one person other than the translator. But if our choice is
between turning away work or accepting it and hoping for review later, I
think the second way would be best.

> Personally, I think you should not have committed r32303:r32306, and
> (unless translations are exempt from the criterion I quoted) I think
> they should be reverted or blessed by someone who speaks Korean.
> Then, if Kang Jeong-Hee wants to maintain the Korean translation, we
> should give him commit access, not commit his patches carte blanche.

Maybe a good way to handle this would be to ping the current Korean
translator(s) and see if they can handle the patches. If they don't
respond, or say they don't have time to handle Kang Jeong-Hee's patch,
then... well, just give Kang Jeong-Hee the ability to commit directly.
There's no reason for the translation to go unmaintained just because
some people hit a busy patch at work or whatever...

Or maybe the above is what Jens is already planning?


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-05 18:05:25 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.