Post by Helge Kreutzmannshim-signed has several errors in debconf translations and pending
translations (cf. 910986 for details) which I intend to rectify.
I tried fixing the errors in the debconf template, for reference, the
original debconf templates are also attached.
I would be happy for review by native speakers befor sending out a
call for (updated) translations.
Okay, commentary inline, diff and revised version attached.
Post by Helge KreutzmannTemplate: shim/title/secureboot
Type: text
_Description: Configuring Secure Boot
^UEFI
Just for consistency.
Post by Helge KreutzmannTemplate: shim/error/bad_secureboot_key
Type: error
_Description: Invalid password
The Secure Boot key you've entered is not valid. The password used must be
between 8 and 16 characters.
(Do we know that it was rejected on the basis of its length? If it
might be invalid for some other reason, it should say what kind of
characters it wants.)
Post by Helge KreutzmannTemplate: shim/disable_secureboot
Type: boolean
Default: true
_Description: Disable UEFI Secure Boot?
If Secure Boot remains enabled on your system, your system may still boot but
any hardware that requires third-party drivers to work correctly may not be
usable.
Template: shim/enable_secureboot
Type: boolean
Default: false
_Description: Enable UEFI Secure Boot?
If Secure Boot is enabled on your system, your system may still boot but
any hardware that requires third-party drivers to work correctly may not be
usable.
Template: shim/secureboot_explanation
Type: note
_Description: Your system has UEFI Secure Boot enabled
UEFI Secure Boot is not compatible with the use of third-party drivers.
.
The system will assist you in toggling UEFI Secure Boot. To ensure that this
change is being made by you as an authorized user, and not by an attacker,
you must choose a password now and then use the same password after reboot
to confirm the change.
.
If you choose to proceed but do not confirm the password upon reboot, Ubuntu
will still be able to boot on your system but the Secure Boot state will not
be changed.
That's only true if it was booting Ubuntu before! This needs to be
de-branded... and besides, we can't guarantee that the machine will
succeed in booting without (e.g.) being struck by lightning!
So maybe:
If you choose to proceed but do not confirm the password upon reboot, the
Secure Boot configuration will not be changed, and the machine will continue
booting as usual.
Post by Helge Kreutzmann.
If Secure Boot remains enabled on your system, your system may still boot but
any hardware that requires third-party drivers to work correctly may not be
usable.
Template: shim/secureboot_key
Type: string
Shouldn't this be "Type: password"?
The text doesn't need to be crammed into the short description. As it
is, this is confusing: I assume we're still talking about the password
for authorising a change to the settings, but this could equally well
be talking about a password to restrict booting.
Also, given that what's happening here is the administrator *setting*
the password, it isn't going to be "asked again" after a reboot -
that'll be the *first* time anyone's challenged to authenticate with
it.
Type: password
_Description: UEFI Secure Boot password
Please enter a password for configuring UEFI Secure Boot.
.
This password will be used after a reboot to confirm authorization for a
change to Secure Boot state.
Post by Helge KreutzmannTemplate: shim/secureboot_key_again
Type: string
There's a standard format for these:
Type: password
_Description: Re-enter password to verify
Please enter the same password again to verify that you have typed it
correctly.
Post by Helge KreutzmannTemplate: shim/error/secureboot_key_mismatch
Type: error
_Description: Password input error
The two passwords you entered were not the same. Please try again.
Okay.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package