Bug#605748: grub-pc: debconf questions should be translated

[Colin Watson]

On Fri, Dec 03, 2010 at 09:34:16AM +0000, Justin B Rye wrote:
> David Prévot wrote:
> > Template: grub-pc/chainload_from_menu.lst
> > Type: boolean
> > Default: true
> > #flag:translate!:6
> > _Description: Chainload from menu.lst?
> >  GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
> >  .
> >  In order to replace the Legacy version of GRUB in your system, it is
> >  recommended that /boot/grub/menu.lst is adjusted to chainload GRUB 2
> >  from your existing GRUB Legacy setup.  This step may be automaticaly
>                                         (1)                          ^
> >  performed now.
> 
> Typo!  s/aly/ally/ (oh, and I'd prefer s/may/can/)
> 
> "Chainload" is jargon, and might put users off from taking this
> step.  Is there a simpler alternative?  Would it be accurate to say
> "adjusted to load a GRUB 2 boot image" (leaving "chainload" in the
> short description)?

That's reasonable.

> (If I understand correctly, whether I say yes here or not I'll still
> have grub-legacy code in my MBR that reads /boot/grub/menu.lst;
> chainloading means that it will be configured to boot a GRUB 2 image
> in a similar fashion to the way grub boots a foreign OS?)

Correct.

> >  .
> >  In either case, whenever you want GRUB 2 to be loaded directly from MBR,
> >  you can do so by issuing (as root) the following command:
> >  .
> >  upgrade-from-grub-legacy
> 
> It's not obvious what the two "cases" are here, and it doesn't
> really mean "do so" (running this command does not immediately cause
> the machine to reboot).  If I understand correctly, the change that
> this command performs is basically retiring all the old grub-legacy
> stuff... hmm, /usr/sbin/upgrade-from-grub-legacy starts by
> "Installing GRUB to Master Boot Record of your first hard drive"
> even if I've declared that I only wanted it on /dev/sdc.  Oh well. 

I'm not sure what your last comment means here.  I can't find that text
in the grub2 source package anywhere.  Are you referring to the source
code line:

  grub-install --no-floppy --grub-setup=/bin/true "(hd0)" > /dev/null

If so, you've misinterpreted it; the --grub-setup=/bin/true means that
"(hd0)" is basically a dummy value.  Running upgrade-from-grub-legacy
should present you with a debconf prompt for where you want to install
GRUB, and then as you say do so and retire any vestiges of GRUB Legacy.
(If that's not the case, perhaps take this to a separate bug report?)

> > Template: grub-pc/install_devices
> > Type: multiselect
> > Choices-C: ${RAW_CHOICES}
> > Choices: ${CHOICES}
> > # Intentionally not marked for translations yet; will do after a review period
> > Description: GRUB install devices:
> >  The grub-pc package is being upgraded.  This menu allows you to select which
>                                          (1)
> >  devices you'd like grub-install to be automatically run for, if any.
> >  .
> >  It is recommended that you do this in most situations, to prevent the installed
> >  GRUB from getting out of sync with other components such as grub.cfg or with
> >  newer Linux images it will have to load.
> 
> Again, "do this" is a bit off (it doesn't mean that you should
> reselect install devices every time).  Can we change it to "Running
> grub-install automatically is recommended in most situations"?

Yes.

> Oh, and s/Linux/kernel/ doesn't hurt...

Or just delete that part since it's extraordinarily rare for new kernels
to actively require a new boot loader (has that ever happened?) and it
distracts people from the fact that if you fail to run grub-install on
upgrades it's normally GRUB itself that will break.

I think perhaps:

  Running grub-install automatically is recommended in most situations,
  to prevent the installed GRUB core image from getting out of sync with
  GRUB modules or grub.cfg.

(Desync with GRUB modules is by far the most common problem.)

> > Template: grub-pc/install_devices_disks_changed
> > Type: multiselect
> > Choices-C: ${RAW_CHOICES}
> > Choices: ${CHOICES}
> > # Intentionally not marked for translations yet; will do after a review period
> > Description: GRUB install devices:
> >  The GRUB boot loader was previously installed to a disk that is no longer
> >  present, or whose normally unique identifier has changed for some reason.
> 
> Wait, "normally" unique?  What does that mean?  If "not much" I
> recommend dropping the adverb.

Dropping the adverb is fine.

> >  It is important to make sure that the installed GRUB stays in sync with
> >  other components such as grub.cfg or with newer Linux images it will have
> >  to load, and so you should check again to make sure that GRUB is installed
> >  to the appropriate boot devices.
> 
> That "and so" is doing some sort of run-on syntactic chainload.  I'd
> suggest just cutting it into two sentences:
> 
>    to load. Please check again to make sure that GRUB is written to the
>    appropriate boot devices.
> 
> (s/installed/written/ here is a minor case of (3) - we're trying to
> keep the MBR synched with the grub.cfg/kernel that are installed...)

It's unfortunate since the upstream terminology is very clearly
"installed", but I agree that it's perhaps confusing with package
installations.

> > Template: grub-pc/disk_description
> > Type: text
> > # Disk sizes are in decimal megabytes, to match how disk manufacturers
> > # usually describe them.
> > _Description: ${DEVICE} (${SIZE} MB, ${MODEL})
> 
> (Needs extra cleverness for languages that don't use MB)

Why?  That whole string is translatable as a unit, so French can and
indeed does translate it to:

  ${DEVICE} (${SIZE} Mo, ${MODEL})

I don't see the problem here.

> Some outside-dle's-jurisdiction whining as usual:
> 
> Why does grub2 spurn my efforts to make all my filesystems readily
> identifiable?  I've got six partitions spread across two 80GB Maxtor
> IDE drives, but I can tell which of them is the root filesystem
> because it's labelled as "MypcRoot" - it's in fstab and everything,
> and I know grub can boot via FS-labels (in fact I seem to recall
> that grub1 let me put them in menu.lst); so why does grub2 insist on
> making me play guess-the-random-ID-code?

Largely because UUIDs always exist while labels only sometimes exist.  I
agree that labels should be presented if they exist; please file a bug
with suggestions on how this might gracefully be done in debconf.

> > Template: grub-pc/install_devices_failed
> > Type: boolean
> > Default: false
> > #flag:translate!:3
> > _Description: GRUB installation failed.  Continue?
>                                          (1)
> If we continue, will the (dpkg sense) grub installation *succeed*?

Yes.

> That seems a recipe for confusion; maybe the question should say
> 
>   _Description: Writing GRUB to boot device failed - continue?

Fair enough.

Thanks,

-- 
Colin Watson                                       [cjwatson at debian.org]