Re: Again about anonymous contributions to DDT*
It unfortunately seems that several contributors, here around, now
seem more interested in quantity than quality,
probably there are people, like me, that don't know very well English,
so they use also the DDTSS to learn, but I think that it is more fast and
simple to correct some wrong words/sentences than translate all from
zero.
How and what do you learn? When you are interested in reading good
english, subscribe to l10n-english. There are for some reasons really
bad translations - as well as there are lots of strange descriptions that
are "word salad" even for native speakers. So there is the real danger
that you may even spoil your English.
What can be learned here is teamwork, how to make and digest fair
comments, making compromises, researching ...
Some texts are very specific - about research software for the life
sciences, numeric math packages and the like. It makes a difference
if you have a clue about the subject or not.
And as Christian stated, it takes much time to correct the "results
of one night stands". There are languages whose structure of
sentences differ from English. One can see if a translator
stepped through the sentence just replacing words by the first
word that comes into his mind ... It *can* be more effort to improve
a weak translation than doing it on your own, especially when it
is your demand to contact the first translator to prevent him from
producing further bullshit.
When you and your team have bad luck, the recipients are pissed
by lots of weak translations and stick to the original.
"support" got by keeping the possibility of anynomous cra^W
contributions.
Probably the anonymous Italian contributor don't are so bad.
For example I start contributing DDTSS as anonymous for about 2-3 month.
Other people have done the same (after a while I encourage they to
take a login and use it, if they are very active).
I think that some Italian anonymous contributor are l10n translators
that sometimes translate/correct some DDTSS packages description.
And I will certainly keep the doors locked for French
I think if the French team have very bad anonymous experience, than
this can be a solution.
I think it was a wise decision from Martijn to make it adjustable on a
per team basis. As teams develop they can change their mind.
Yesterday Christian mentioned some real problems with inexperienced
translators. It would be great to know the French guys attracted so
many people that they could keep up with the Linux man-pages and
produce software such as po4a.
dudes who translate everything....but insist on translating *well*
more than translating *a lot*).
(you know...those
but in some case there is need to translate *a lot*, or better there
is a lot of very easy work to do, for example:
* short description now without article or uppercase/lowercase ("a
blue game" -> "blu game" or "Blue game" -> "blue game" or "Blue Game"
-> "Blue game");
<snipped some more examples>
You already mentioned in several other posts that you are working
on ways to detect those tasks and ease the work. It should be
automated as far as possible to better utilize our manpower.
I think that DD must try to facilitate the translation work:
1) try to use some standard paragraphs
for example for abc-dbg:
"This package contain the debug symbols."
and not
"This package contain the debug symbols for abc."
If the package is named abc-dbg than you already know that the debug
symbols are for the abc packages;
2) avoid use of multiple space, use upper case for name (es: Perl and
not Perl), ending each paragraph with a point, ...;
3) do not make change unnecessary (for example change the layout);
4) ...
Yep. There are lots of wordings for debug/doc/dev that could be
standarsized or omitted. I hope for Levenshtein and Martijn' work
to solve the problems of the last to points of your enumeration.
It feels nice to have lots of translations and have a good ranking among
the translation teams.
But it is boring and tedious to translate dozens of "This package contains
the xx language package for $real_fat_package". But as above - do we
really need this when the package is suffixed "l10n-xx"?
Or
First Paragraph: boilerplate explaining some software ...
.
This package contains the $some_name extension.
Yeah. Low hanging fruit - one easy to translate sentence, just one row,
improving the statistics.
Another point of view: This description is of little use. Well, I have a
plug-in for some software. I obviously don't need it when the base
software is not installed. But I would like to know is, what this
plug-in can do for me. One could postpone the translation and
file an RC bug. Copied from debian policy:
3.4 The description of a package
Every Debian package must have a Description control field which
contains a synopsis and extended description of the package.
Technical information about the format of the Description field is in
Description, Section 5.6.13.
** The description should describe the package (the program) to a user
(system administrator) who has never met it before so that they have
enough information to decide whether they want to install it. ** This
description should not just be copied verbatim from the program's
documentation.
Ciao,
Martin
Reply to: