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

Re: When to ask for a review?



Quoting Martin Eberhard Schauer (Martin.E.Schauer@gmx.de):
>     Hi Christian,
> 
> feel free to post parts of this mail when they fit better somewhere else.

Well, your question brings many issues and I'm unsure I'll have time
to answer all of them properly (just had very bad family news last
night and have no idea about my involvment in the next days...probably
the same than before but not on deep discussions, probably)

I'll address a few points.


> > 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

Writing a bug report is always a good start. At least saying something
like "I find this package description could be improved. Feel free to
get in touch with debian-l10n-english" to initiate a review"....would
leave part of things up to the maintainer.

We should also take care to avoid flooding dle with reviews to
do. They require a significant amount of time and our resources are
limited here, too. 2 or 3 native speakers, that's all.

> Another possibility is to improve the infrastructure. I suppose that German
> descriptions for Telegu related packages are not as effective as
> Telegu ones.

There are very few Teluigu-specific packages...or ingeneral packages
related to a specific language (an example is the package related to
Bulgarian dictionaires, for which a call for trnaslations was just posted)

> 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?

Nope. Neither country nor language. popcon stats are very anonymous.

> 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

Repetitive paragraphs (which we described as "boilerplates" in dle
jargon) are done on purpose. The point is that each binary package
description is autonomous and doesn't need to point back to a "main"
package that would have the whole software description.

These do not require additionnal l10n effort, as you pointed, so it's
a goo dcompromimse.

> 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).

That requires many developments in the packaging software. As of now,
nobody volunteered for this, unfortunately.

> >> 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!"

You most often don't need the whole source. This is just the most
practical way to get things (I do have a local mirror at
home..:-)). And, as you point, in some (very specific, though) cases,
that might be needed.


> I will first have a look at the wiki. Perhaps »vidalia« will be the first
> victim..


This is how I started: with package description that I *really*
disliked..:)


Attachment: signature.asc
Description: Digital signature


Reply to: