Re: When to ask for a review?
Hi Christian,
feel free to post parts of this mail when they fit better somewhere else.
> (not sure if you're subscribed. Assuming you aren't: please tell if
> you don't need|want to be CC'ed)
After following the list for some days, i subscribed yesterday. Besides
i am subscribed to i18n.
> ... from your recent activity, you seem to be interested in doing
even more. ...
I hope, at least the quality will not decease.
To be honest, primarily I wanted to do something different. The previous
work had
annoying aspects:
- several endless iterations with changes introducing new bugs,
- the amount of new and changed descriptions with too little
manpower in the team,
- the language skills of both maintainers and translators (do you know
how often non-native speakers don't use the s in the third person
singular?) - it's hard not to become lazy when many others already are,
- unsufficient knowledge where to gather information for individual goals
(eg. keep a certain subset of translations up to date),
- limitations in infrastructure.
I would like to quote from my discussion on i18n with Helge:
(http://lists.debian.org/debian-i18n/2010/04/msg00037.html)
> I believe there is interest in searching packages that match some
> translation criteria:
> (http://lists.debian.org/debian-i18n/2010/03/msg00057.html)
>
> The script has been used by some Italian team people and he can help to:
> * automatic fetch package in http://ddtp.debian.net/ site
> * identify packages that can have translated paragraphs
> * identify packages that need to be translated and have only few text
> rows
Thus i was glad to see what Clytie wrote today:
(http://lists.debian.org/debian-i18n/2010/04/msg00047.html)
> ... How do we know where our efforts are most effectively allocated?
> Should I be spending my time translating every debconf template in
> existence, or is it more useful to Debian if I work on certain package
> descriptions, package strings or docs?
> How do we know what should be translated before others?
> ... So how _do_ we find out where our localization effort is best
> allocated? How do we get an overall picture of a package's translation
> status: package descriptions, debconf, program strings and docs?
****************
> Here comes the list.
>
>> What are good criteria for asking the list for help?
>
> When you think that a package description could be improved in some
> way. I can't see any specific criterion.
I think limited resources are important. Everything can't be done and
this even makes sense: translating descriptions prior to etch is just
a waste of manpower. Therefore it seems wise to focus on something
where there is a good ratio between result and effort.
One possibility could be writing a bug report or initiating a review
for a poor description. Ideally the new, improved description is better
understood by the translators and their overall throughput is improved
(because they found the better translation before the old one).
Another possibility is to improve the infrastructure. I suppose that German
descriptions for Telegu related packages are not as effective as Telegu
ones.
Or think of Clytie: i think she would be glad to translate things that are
really useful for vietnamese people. Does popcon already provide
country-specific statistics ore are they just global?
Another example: when i detect a source package extensively recycling
descriptive paragraphs lots of new partially translated descriptions are
produced. When i decide to bypass the (three) reviews for paragraphs
such as
"This package provides the development headers and the static library ..."
and SDs like "foo, a framework for bar - development
files/documentation/debug symbols/bindings for" and use the e-mail
interface
for ddtp, i have to write a dozen e-mails. Perhaps standardisation and the
use of variables in the descriptions would take part of this boaring
routine
work from the translators (think of kernel packages, language packs for
office suites, desktop environments and browsers).
>> How can I contribute?
>
> Do the initial work:
>
> - grab the package source
> - modify the debian/control file according to what you think is right
> - create a diff
Does one really need the whole sources? Will sdrp-toolkit-0.4 help? Or
did i miss something more comfortable than downloading three files and
calling dpkg-source? And even this does not work in all cases:
debian-science -> debian/control:
" #This file is autogenerated via make -f debian/rules dist. Do not edit!"
> - post an RFR message ...
> - gather comments and suggestions ...
>
> You can get more details ...on wiki.debian.org.
I will first have a look at the wiki. Perhaps »vidalia« will be the first
victim..
Cheers
Martin
Reply to: