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

Re: Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings



Neil Williams <codehelp@debian.org> writes:

> The source package check can only process the msgfmt output which is
> overly brief. msgfmt does not say whether all translations are missing
> the *same* string, it just says that all translations are missing *a*
> string.

Oh!  Yes, thank you.  That was the point that I was missing.  So the
existing check does have false positives that the check you outline would
not for the problem that you're trying to detect.

If I check the generated templates in the binary deb, how do I check that
the string was marked for translation?  We don't want to trigger this tag
on strings that aren't intended to be translated.

>> It's certainty: possible right now because there may be cases where
>> translators were warned but didn't have a chance to do any translations
>> (for an obscure package, for instance).  I think that will always be
>> the case.

> Then maybe an override can quote the message to debian-18n in the
> comments, just as other overrides are meant to quote the bug number? 

> If other questions in the templates file *are* translated, it seems
> highly unlikely to me that none of the previous translators and none of
> the other language teams responded to the call for updates - as long as
> a sane deadline was set.

That's a good point.  If we check that other things are translated but
this question was not, that's a fairly conclusive sign that the
translators are willing to work on the package and just haven't had an
opportunity to do so.

>> debian-mentors discussion also raises the valid point that a brand new
>> package possibly shouldn't go to translators before the first upload.
>> I'd like to get a debian-i18n opinion on that as well.  Should we skip
>> the Lintian tag for no complete translation if this is the first
>> packaging?  (We can detect this by noting that we only have one
>> changelog entry.)

> I disagree with that analysis of the discussion on mentors - I think a
> brand new package *should* go to translators before the first upload
> and gave my reasons in the thread. New packages using debconf should
> have their templates reviewed.

Okay.  I'll defer to the debian-i18n consensus on this, since it's y'all's
resources that are at stake here.

>> Remember, the rule of thumb here is that severity should match the
>> severity that you'd pick for the bug that you filed about the problem,
>> were you to file a bug.  Important is a rather large leap over the
>> current severities used for translations.

> Debconf is a little different. It is a peculiar problem that if a new
> debconf question is not translated, the user does not get the chance to
> reconsider their answer when the translation finally arrives.

> Normal severity would be fine if important is deemed a step too far.

> I still think it is worth enforcing "no untranslated debconf questions"
> in debian-mentors as a point of good practice - even if the lintian tag
> severity is not changed in order to avoid annoying existing DD's.
> Mentors should be about raising the quality of NEW packages and package
> updates (especially QA uploads etc.) and all packages coming through
> mentors should be up to the latest measures of Policy, Standards and
> general behaviour.

Sure.  I believe that when mentoring you should always run lintian with -I
and ask mentees to fix info-level tags as well (unless they're just
wrong).  Info-level tags are intended to be best practices that people who
don't have a solid reason for doing otherwise should follow, which
describes fairly well the typical mentoring situation.

> Maybe lintian could be more aggressive for checks performed during
> sponsoring than when being used by more "experienced" DD's. ;-)

My hope is that the existing distinction between info and warning, and the
upcoming pedantic support, will provide that extra level of aggressiveness
for those who want it.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: