Neil Williams <codeh...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org