Thread (14 messages) flat view 14 messages, 5 authors, 2016-06-15

Re: Using Transifex in git.git

From: Michael Witten <hidden>
Date: 2016-06-15 22:51:28

On Wed, Jun 15, 2011 at 13:21, Erik Faye-Lund [off-list ref] wrote:
On Tue, Jun 14, 2011 at 7:57 AM, Ramkumar Ramachandra
[off-list ref] wrote:
quoted
I think it's a good idea to use a system like Transifex to manage
translations for git.git, so that we can attract a large number of
non-technical translators.
Are we sure we want non-technical translators to translate Git, a
highly technical program with many technical terms?

I'm guessing that Git probably should be translated by it's users,
because we have a lot of Git-jargon that is difficult for people who
doesn't know Git to translate. But perhaps an initial translation for
each language is enough to establish a language-specific translation
of all Git-jargon, and then afterwards we can get help from
non-technical people to improve the language? I'm just asking, I don't
know how Transifex works at all...
I think your second paragraph ALMOST has the right of it.

Open source showed us the virtue of "Release early and release often";
it's best to get people using something even if it's crap at first,
especially because people can then figure out what needs to be
bettered.

Wikipedia showed us that if we reduce the requirements to contribution
(which, if you think about it, also means that backwards compatibility
must be largely forgone), then the net result is a constantly and
rapidly improving product (albeit with minor but inconsequential
setbacks due to fools and miscreants).

So, who cares if the translation for the Nǁngǃke language (look it up)
is initially junk at first; if it's easy to fix, then it will rapidly
improve into a steady state of high quality.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help