Bug#388824: select-with-translated-default-field may be a bit overzealous
On Tue, 2006-09-26 at 21:20 -0700, Russ Allbery wrote: Attached is a patch that checks source packages instead of binary packages. There are different advantages for this solution: This sounds good, thanks Thomas for the patch and Russ for swiftly applying it. Thijs signature.asc Description: This is a digitally signed message part
Bug#388824: select-with-translated-default-field may be a bit overzealous
Hi, Russ Allbery [EMAIL PROTECTED] (26/09/2006): Thomas Huriaux [EMAIL PROTECTED] writes: Attached is a patch that checks source packages instead of binary packages. There are different advantages for this solution: * it can easily ignore Default: fields with brackets (i.e. when the maintainer obviously wants this field translated). These brackets are not included in the binary packages. * it catches the problem even if the package is not translated yet * it includes other types (not only select and multiselect, it is common to see things such as Default: true in case of boolean templates marked as translatable). I was a little worried about templates of type string, but looking through the debconf templates on my system, marking those translatable appears to be a problem more often than not. For example, I'm going to go file a bug against the postfix packages, since the default for postfix/root_address is translated but the postfix.postinst script will treat the translated value as a recipient e-mail address since it looks only for NONE. The common case is noise in the translation templates for things like numbers and file paths that shouldn't ever be translated. Note that it should also be seen as a warning that requests documentation for translators. For example, if we have a default string marked as translatable such as _Default: None Either it should not be translated (as in postfix), or it can be translated as it will be part of the title of a webpage (just an example, of course). Asking the maintainers to say so as following: _Default: None[ This will be part of a webpage title ] is in my opinion more an advantage than a disadvantage. So I think this is the right thing to do, although we'll see if we get any pushback after the next lintian release. Thanks a lot for your work. -- Thomas Huriaux signature.asc Description: Digital signature
Bug#388824: select-with-translated-default-field may be a bit overzealous
Thomas Huriaux [EMAIL PROTECTED] writes: Note that it should also be seen as a warning that requests documentation for translators. For example, if we have a default string marked as translatable such as _Default: None Either it should not be translated (as in postfix), or it can be translated as it will be part of the title of a webpage (just an example, of course). Asking the maintainers to say so as following: _Default: None[ This will be part of a webpage title ] is in my opinion more an advantage than a disadvantage. Just to confirm, this syntax works for type string as well, right? Not just select and multiselect? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388824: select-with-translated-default-field may be a bit overzealous
Russ Allbery [EMAIL PROTECTED] (27/09/2006): Thomas Huriaux [EMAIL PROTECTED] writes: Note that it should also be seen as a warning that requests documentation for translators. For example, if we have a default string marked as translatable such as _Default: None Either it should not be translated (as in postfix), or it can be translated as it will be part of the title of a webpage (just an example, of course). Asking the maintainers to say so as following: _Default: None[ This will be part of a webpage title ] is in my opinion more an advantage than a disadvantage. Just to confirm, this syntax works for type string as well, right? Not just select and multiselect? I confirm, this feature does not depend on the type of template. Cheers, -- Thomas Huriaux signature.asc Description: Digital signature
Bug#388824: select-with-translated-default-field may be a bit overzealous
tags 388824 patch
thanks
Hi,
Thijs Kinkhorst [EMAIL PROTECTED] (22/09/2006):
Our package uses a translated DefaultChoice field in the debconf
templates, exactly as described in DevRef 6.5.4.4.
Lintian triggers a warning on this: select-with-translated-default-field.
Since the warning doesn't apply, I'm overriding it. However, the warning
is triggered for every occurrence in every po file. That means I'm now
putting two overrides per language in our lintian-overrides file:
select-with-translated-default-field mailman/site_languages hu.utf-8
select-with-translated-default-field mailman/default_server_language hu.utf-8
select-with-translated-default-field mailman/site_languages ja.utf-8
select-with-translated-default-field mailman/default_server_language ja.utf-8
[...]
I think you'll get my point: we've got 13 languages already, equals 26
overrides, and I expect this to only grow. Adding two overrides for
every language that we add is not ideal.
So my question here is: is there a better way to solve this? Some ideas,
in my order of preference, I don't know what's best or possible from
your point of view though:
1) Remove the test altogether. If I do not mark DefaultChoice as
translatable, then it will not appear in the .po file template, so
what's the chance of someone translating it nonetheless? And if they
do, it will be ignored so no harm done. I'm wondering what the test
tries to accomplish.
2) If the test is actually needed, make sure it does not trigger if
DefaultChoice was marked as translatable. If it's marked as such, the
package maintainer intends for it to be translated.
3) Trigger the warning only once for a package.
4) Make the warning overridable categorically, i.e. I add
select-with-translated-default-field mailman/site_languages and all
those warnings will be overridden regardless of the last bit.
Attached is a patch that checks source packages instead of binary
packages. There are different advantages for this solution:
* it can easily ignore Default: fields with brackets (i.e. when the
maintainer obviously wants this field translated). These brackets are
not included in the binary packages.
* it catches the problem even if the package is not translated yet
* it includes other types (not only select and multiselect, it is
common to see things such as Default: true in case of boolean
templates marked as translatable).
Cheers,
--
Thomas Huriaux
diff -ur /usr/share/lintian/checks/debconf checks/debconf
--- /usr/share/lintian/checks/debconf 2006-09-04 21:03:38.0 +0200
+++ checks/debconf 2006-09-26 15:01:06.0 +0200
@@ -215,10 +215,6 @@
# Tests on translations
my ($mainfield, $lang) = split m/-/, $field, 2;
if (defined $lang) {
- if ($isselect and $mainfield eq 'default') {
- tag select-with-translated-default-field,
- $template-{template} $lang;
- }
$languages{$lang}{$mainfield}=1;
}
unless ($template_fields{$mainfield}) { # Ignore language codes here
diff -ur /usr/share/lintian/checks/debconf.desc checks/debconf.desc
--- /usr/share/lintian/checks/debconf.desc 2006-09-04 21:03:38.0
+0200
+++ checks/debconf.desc 2006-09-26 14:58:24.0 +0200
@@ -87,11 +87,6 @@
is a duplicate of the short description. If you cannot provide a good
extended description, it is better to leave it blank.
-Tag: select-with-translated-default-field
-Type: warning
-Info: You do not need to translate `Default:' fields of `select' or
- `multiselect' questions in templates.
-
Tag: partially-translated-question
Type: warning
Info: If you translate the `Choices:' fields in a template, you should
diff -ur /usr/share/lintian/checks/po-debconf checks/po-debconf
--- /usr/share/lintian/checks/po-debconf2006-05-17 04:09:04.0
+0200
+++ checks/po-debconf 2006-09-26 14:58:24.0 +0200
@@ -38,6 +38,13 @@
$has_template = 1;
if ($file =~ m/templates\.\w\w(_\w\w)?$/) {
push (@lang_templates, $file);
+ } else {
+ open(PO, debfiles/$file)
+ or fail(Can't open debfiles/$file file.);
+ while (PO) {
+ tag translated-default-field, $file: $.
+ if (m/^_Default(Choice)?: [^[]*$/);
+ }
}
}
}
diff -ur /usr/share/lintian/checks/po-debconf.desc checks/po-debconf.desc
--- /usr/share/lintian/checks/po-debconf.desc 2006-05-07 08:26:02.0
+0200
+++ checks/po-debconf.desc 2006-09-26 14:58:24.0 +0200
@@ -63,3 +63,14 @@
This can be ensured by running debconf-updatepo in the 'clean' target
of ttdebian/rules/tt. PO files will then always be up-to-date when
building the source package.
+
+Tag: translated-default-field
Bug#388824: select-with-translated-default-field may be a bit overzealous
Thomas Huriaux [EMAIL PROTECTED] writes: Attached is a patch that checks source packages instead of binary packages. There are different advantages for this solution: * it can easily ignore Default: fields with brackets (i.e. when the maintainer obviously wants this field translated). These brackets are not included in the binary packages. * it catches the problem even if the package is not translated yet * it includes other types (not only select and multiselect, it is common to see things such as Default: true in case of boolean templates marked as translatable). I was a little worried about templates of type string, but looking through the debconf templates on my system, marking those translatable appears to be a problem more often than not. For example, I'm going to go file a bug against the postfix packages, since the default for postfix/root_address is translated but the postfix.postinst script will treat the translated value as a recipient e-mail address since it looks only for NONE. The common case is noise in the translation templates for things like numbers and file paths that shouldn't ever be translated. So I think this is the right thing to do, although we'll see if we get any pushback after the next lintian release. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388824: select-with-translated-default-field may be a bit overzealous
Package: lintian Version: 1.23.24 Severity: minor Hello, Our package uses a translated DefaultChoice field in the debconf templates, exactly as described in DevRef 6.5.4.4. Lintian triggers a warning on this: select-with-translated-default-field. Since the warning doesn't apply, I'm overriding it. However, the warning is triggered for every occurrence in every po file. That means I'm now putting two overrides per language in our lintian-overrides file: select-with-translated-default-field mailman/site_languages hu.utf-8 select-with-translated-default-field mailman/default_server_language hu.utf-8 select-with-translated-default-field mailman/site_languages ja.utf-8 select-with-translated-default-field mailman/default_server_language ja.utf-8 [...] I think you'll get my point: we've got 13 languages already, equals 26 overrides, and I expect this to only grow. Adding two overrides for every language that we add is not ideal. So my question here is: is there a better way to solve this? Some ideas, in my order of preference, I don't know what's best or possible from your point of view though: 1) Remove the test altogether. If I do not mark DefaultChoice as translatable, then it will not appear in the .po file template, so what's the chance of someone translating it nonetheless? And if they do, it will be ignored so no harm done. I'm wondering what the test tries to accomplish. 2) If the test is actually needed, make sure it does not trigger if DefaultChoice was marked as translatable. If it's marked as such, the package maintainer intends for it to be translated. 3) Trigger the warning only once for a package. 4) Make the warning overridable categorically, i.e. I add select-with-translated-default-field mailman/site_languages and all those warnings will be overridden regardless of the last bit. By the way, thanks for your maintenance of Lintian, it really helps to make Debian packages better! Thijs signature.asc Description: This is a digitally signed message part
