Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] Raspberry Pi translation team looking for Japanese translator



Furkan Mustafa writes:

 > Hmm.. To me, it looks like they ask for free work.

They did.  I've done a fair amount of free work, and my projects have
received great benefit from other's free work.  Asking is not
receiving, you get a lot of crap -- even the good stuff ages rapidly
(and not like wine) -- unless the project is popular enough to be able
to have multiple people working on the translations.

If you don't want to do unpaid work, don't do it.  It's no harder than
that.  It's not like being "asked" to do overtime by your boss.

 > I don't get why such a profession would be unpaid.

The profession isn't.  I've also been paid (well) for it (though that
is quite rare for me personally, I contribute far more than I get paid
for).  Any given task might be paid or unpaid.

Why do projects choose any particular way of resourcing (paid or
unpaid)?  One reason for calling for volunteers is community-building.

Building a community is a very delicate task.  While Mozilla is a very
successful project in many ways, folks like Jamie Zawinski who pushed
for the open-sourcing of the Netscape code were rather disappointed in
both the backbiting from a few people in the broader community who
didn't understand the complexity and legal constraints involved in
such a project, and in the Mozilla community as it developed.  That
day there were many thousands of downloads, demonstrating enormous
interest in the code.  Yet the flood of contributions they expected
didn't materialize, and there was carping from the very beginning
about the dominance of former Netscape employees in the project.  That
project has stabilised, and obviously is successful.  But it's one of
the harder ones to get involved in compared to many others that were
volunteer projects from the beginning.

Crowd-sourcing turns out to be a pretty effective way to do both
translation of technical manuals/websites for smaller projects, and
community development.  It's not just financial (saving money), it's a
matter of organizing a community (and every company *is* a community,
that's what "company" means under the tons of connotations the word
has today when used to denote a business firm).  With appropriate
software, it is easy for a triple threat developer (you need two
natural languages and some domain knowledge) to go, translate a few
paragraphs in ten minutes, and leave the rest for somebody else.  I
don't know about you, but for me it's way more satisfying than normal
bug reporting -- not only do I make it possible to fill in a gap, I
actually contribute to doing just that.  If momentum builds up, those
paragraphs add up quickly.  But it would be hugely expensive if you
paid those people; the overhead in line management and the accounting
department would be as much as or more than the direct compensation.

I've worked with volunteer documentation translators in Mailman and
Debian, and they tend to be non-technical people with minimal
understanding of the inside working of the code.  They're frequently
very enthusiastic about their contributions and attached to the
projects they work on.  Not a few are professional translators who
do it for the feeling that comes with being part of a community of
users supporting each other, rather than just churning out minimally
useful half-understood "setsumei-sho" as quickly as possible.  (The
greybeards may remember the famous line from _Zen and the Art of
Motorcycle Maintenance: "Assembly of Japanese bicycle require great
patience."  The author went on to praise that as a "*good*
instruction", but as English, it's pretty weak.)

Translators are a very different kind of contributor from coders, and
the rank and file don't mix well.  They don't hate each other, they
just don't enjoy interaction very much.  But for the core maintainers,
they provide enthusiasm and interaction with people who have a
viewpoint much closer to the non-technical user.  They tend to be
supportive rather than critical.  Criticism is technically necessary
to building a great project, but the support is socially and
psychologically constructive.

One may question bringing in non-native speakers of the target
language to translate, but truly bilingual people across language
groups (in particular, Japanese and Korean constitute a group to
themselves) are very rare, even among professional translators.  In
technical prose, translation bugs are *almost always* shallow.  The
"many eyes" approach is most effective here.  In my experience, the
best translations come about from interactions between native speakers
of the source and target languages.  Idioms are hard, and rarely map
directly to idioms (although they sometimes do, as in "do as the
Romans do" and "郷に従う").  So "mechanical translation" is the usual
result of delegating large chunks of text entirely to one translator,
regardless of whether they're source-native or target-native.
Crowd-sourcing to volunteers is an effective way to combine both
perspectives.

About pay: CxO at GBP10,000/month is effectively contributing between
GBP40,000/month and GBP400,000/month to the company, I hate to tell
you, depending on where they'd land in the for-profit-only sector.
It's not hanakuso by middle management or non-elite tech worker
standards, but it's way less than people with those skills normally
get paid (even in socialist *cough* countries like France, Sweden, and
Germany, let alone "red in tooth and claw" capitalist countries like
pre-Brexit Britain).

Regards,
Steve

-- 
Associate Professor              Division of Policy and Planning Science
http://turnbull.sk.tsukuba.ac.jp/     Faculty of Systems and Information
Email: turnbull@example.com                   University of Tsukuba
Tel: 029-853-5175                 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links