Re: Manpages translation
Hi, Denis and hmh
On Wed, Mar 05, 2003 at 12:19:05PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 05 Mar 2003, Denis Barbier wrote:
> > I strongly disagree, you are asking too much, translators can't
I would have said:
I strongly disagree, you are asking too much, not all translators can't.
^^^^^^^
> Like hell I am. I've been there and done that, for 3 years, and I had to
> not only learn to read C code, but also get involved into crypto (so as to
> learn how to translate the proper technical terms) to get the job right.
You are talking 2 issues here.
1. If English original is crystal clear but has few special
terminologies which requires technical insights, check and learn
their translation conventions elsewhere.
2. If English original has ambiguity, translator can read the sources
by himself to proofread English original or may communicate with the
upstream/package maintainers for its clarification.
I think it is desirable to have high quality translator who can function
also as an proofreader of the English original but it should not be the
prerequisite of the translator as long as he exhibit due diligence of
asking others for clarification.
Of course, appointing some one who has such a high standard like hmh in
the senior position to guide junior translators a good idea but hmh can
not translate everything.
> And I *do* think we are better off with something untranslated than
> something with crappy l10n.
l10n does not block access to the original information. Your position
sounds too harsh to me. I agree *crappy* is bad, though. If you find
such a crappy translation, 2nd best thing is to file bug report to
remove po file. (Of course you can send a updated po file)
I think small bugs and delays are tolerated for l10n as long as we are
willing to fix them. I think question is how to implement
accountability infrastructure for documentation contents including
translation.
> > - follow Debian dedicated ML
> No.
>
> > - subscribe to the PTS
> No, if the DDTS already tells them when they are to update something. And
> if it doesn't, it certainly could.
>
> > - download and read the sources
> > for all their packages.
>
> YES. Every time something isn't 100% clear they ARE to READ the source, and
> find out exactly what the sentence means, so as to translate it right.
It is no doubts the best way but not the only way....
> Or do you expect me to hold translators to a lesser level of responsibility
> and technical excellence than the rest of the people involved [with
> Debian/GNU/whatever]? Sorry, but I refuse to. I will not insult those
> translators who do high-quality work, by holding their peers to low
> standards.
>
> > Consider a French translator who finds an error in sylpheed/fr.po.
> > He runs
> > $ apt-get source sylpheed
> > but there is no po/ directory. Too bad, its maintainer is using his own
> > f*cking packaging system so that only geeks can work on it (and of
> > course in this case the fr.po file is patched!).
>
> Well, that's something different.
>
> For this case, the translator does a dpkg-buildpackage, and goes poke at the
> unpacked and compiled source (he is quite welcome to ^C the build, the
> sources will have been unpacked by then).
>
> It is also perfectly workable to start requiring in policy a debian/whatever
> doc that tells one how to unpack, and where the source in its final
> (pre-build) format will be found. But no translator ever asked for this
> seriously to the point of proposing the policy changes.
>
> > I want a system similar to the Free Translation Project used for years
> > by GNU folks: developers send PO files to a mail server, which sends
> > them to each language list. Then translators update them and send them
> > back to the robot which forwards them to developers.
> And you get half-assed, often completely wrong translations a-plenty, to the
> point that people who knows enough english (like me) end up doing a
> LC_MESSAGES=en_US (or C) to get something they can understand back from a
> program. Even if by doing that I have to forsake my own mother language
> (that happens to be MUCH better than English as far as I am concerned), so
> that I can get some work done.
>
> Oh, there *ARE* a lot of very good translators that don't just pretend they
> understand something, and actually go to the pain of clearing up any doubts
> they have (by asking the code developer, or looking at the source). But
> there are also a huge lot of them who don't. I know quite a few from the
> pt_BR "l10n scene".
I understand your feeling but ... some people can not read English at
all. So it is better than nothing :-)
As for addressing hmh's legitimate concern, one way is to have rating
system for translators. But we do not even have official rating system
for package maintainer. In volunteer system, this type of thing may
discourage new translators. The best solution is that someone like hmh
guides new translators to the higher standard through leadership and
mentoring, I think.
Anyway, this content accountability issue is not just translation but
Debian in general. (How do you know an obscure package in our archive
without any bug reports is really as secure as some normal packages with
several security bug reports? Chances are it is less secure despite its
bug status.)
--
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +++++
Osamu Aoki <osamu@debian.org> Cupertino CA USA, GPG-key: A8061F32
.''`. Debian Reference: post-installation user's guide for non-developers
: :' : http://qref.sf.net and http://people.debian.org/~osamu
`. `' "Our Priorities are Our Users and Free Software" --- Social Contract
Reply to: