[LCFC] templates://grub2/{templates} (Was: Bug#605748: grub-pc: debconf questions should be translated)
David Prévot
david at tilapin.org
Tue Dec 7 14:07:54 UTC 2010
Le 03/12/2010 05:34, Justin B Rye a écrit :
> It's too early in the day (-14°C outside!) for me to expect to
> get this all right without typos/thinkos, so extra feedback is
> definitely welcome.
Thanks Justin,
May I push this further: in order to hopefully get those reviewed
templates and according translations in time for Squeeze, I'm afraid
that we have to hurry a bit (and important untranslated templates like
this ones is really a shame for Lenny to Squeeze upgrades).
Please find attached the last reviewed version of grub-pc.templates.in,
with no other changes than s/Description/_Description/ (and relative
comments deleted) from Justin's review. Justin following comments are
copied verbatim for Colin and other grub2 maintainers benefits.
Justin, I also attached templates.in that may need some consistency
review according to your previous comments (some easily fixable (1) and
some (2) in the last template I haven't fixed yet).
If no one objects, I'd like to send a five day call for translation
update tonight, hoping that further templates update will introduce no
meaning change.
Regards
David
> Overall comments:
> 1) The inter-sentence punctuation is doublespacey throughout; en_US
> styleguides prefer singlespaced.
> 2) There are some uses of second person (things like "do you want
> to install grub to your computer's MBR") where in principle I
> might be a sysadmin reluctantly following corporate IT policy
> for the company's servers. On the other hand every time we
> flatten those out we run the risk of reducing clarity for the
> users who *are* in charge of their own machines, and the worst
> case scenario of an unbootable machine is a significant risk
> here, so I have left most cases unchanged.
> 3) The terminology used for the process of writing to a bootsector
> needs to be kept clear; talking about "installing GRUB" can be
> confusing, since after all these templates are used *after* I've
> installed grub in the dpkg-deb sense.
>
>> 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)?
>
> (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?)
>
>> .
>> It's recommended that you accept chainloading GRUB 2 from menu.lst, and
>> verify that your new GRUB 2 setup is functional for you, before you install
>> it directly to your MBR (Master Boot Record).
>
> Some (2) and (3) - we could make it "verify that the new GRUB 2
> setup works before it is written to the MBR (Master Boot Record)."
>
>> .
>> 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.
>
> Whatever your decision, you can replace the old MBR image with GRUB 2
> later by issuing the following command as root:
>
>> 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"?
>
> (Personally I prefer the spellings "synch/synching" to
> "sync/syncing", but I seem to be in a minority so I'll leave it.)
>
> Oh, and s/Linux/kernel/ doesn't hurt...
>
>> .
>> If you're unsure which drive is designated as boot drive by your BIOS, it is
>> often a good idea to install GRUB to all of them.
>> .
>> Note: It is possible to install GRUB to partition boot records as well, and
>> some appropriate partitions are offered here. However, this forces GRUB to
> (1)
>> use the blocklist mechanism, which makes it less reliable, and therefore is
>> not recommended.
>
> I often complain about "Note:", but I think it's okay here, except
> that styleguides prefer lowercase after a colon.
>
>> 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.
>
>> 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...)
>
>> .
>> If you're unsure which drive is designated as boot drive by your BIOS, it is
>> often a good idea to install GRUB to all of them.
>> .
>> Note: It is possible to install GRUB to partition boot records as well, and
> i
>> some appropriate partitions are offered here. However, this forces GRUB to
>> use the blocklist mechanism, which makes it less reliable, and therefore is
>> not recommended.
>>
>> 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)
>
>> Template: grub-pc/partition_description
>> Type: text
>> # The "-" is used to indicate indentation. Leading spaces may not work.
>> Description: - ${DEVICE} (${SIZE} MB, ${PATH})
>
> (Ditto)
>
> 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?
>
>> 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*?
> That seems a recipe for confusion; maybe the question should say
>
> _Description: Writing GRUB to boot device failed - continue?
>
>> GRUB failed to install to the following devices:
>> .
>> ${FAILED_DEVICES}
>> .
>> Do you want to continue anyway? If you do, your computer may not start up
> (1)
>> properly.
>>
>> Template: grub-pc/install_devices_failed_upgrade
>> Type: boolean
>> Default: true
>> #flag:translate!:3
>> _Description: GRUB installation failed. Try again?
>
> (Ditto)
>
>> GRUB failed to install to the following devices:
>> .
>> ${FAILED_DEVICES}
>> .
>> You may be able to install GRUB to some other device, although you should
>> check that your system will boot from that device. Otherwise, the upgrade
> (1)
>> from GRUB Legacy will be cancelled.
> canceled
> (en_US)
>
>> Template: grub-pc/install_devices_empty
>> Type: boolean
>> Default: false
>> _Description: Continue without installing GRUB?
>> You chose not to install GRUB to any devices. If you continue, the boot
>> loader may not be properly configured, and when your computer next starts
>> up it will use whatever was previously in the boot sector. If there is an
>> earlier version of GRUB 2 in the boot sector, it may be unable to load
>> modules or handle the current configuration file.
>> .
>> If you are already running a different boot loader and want to carry on
>> doing so, or if this is a special environment where you do not need a boot
>> loader, then you should continue anyway. Otherwise, you should install
>> GRUB somewhere.
>
> Three (1)s and a low-hanging (2): "when s/your/this/ computer..."
>
> Am I "running" a boot loader in between boots? s/running/using/
>
>> Template: grub-pc/postrm_purge_boot_grub
>> Type: boolean
>> Default: false
>> # This should get reviewed before it can be translated
>> Description: Remove GRUB 2 from /boot/grub?
>> Do you want to have all GRUB 2 files removed from /boot/grub?
>> .
>> Your system would be then unbootable if you don't install another bootloader.
>
> Elsewhere written as two words, "boot loader". Rephrase more alarmingly, also
> eliminating (2):
>
> This will make the system unbootable unless another boot loader is
> installed.
>
>> Template: grub-pc/mixed_legacy_and_grub2
>> Type: boolean
>> Default: true
>> #flag:translate!:3
>> _Description: Finish conversion to GRUB 2 now?
>> This system still has files from the GRUB Legacy boot loader installed, but
>> it now also has GRUB 2 boot records installed on these disks:
>> .
>> ${DISKS}
>> .
>> It seems likely that GRUB Legacy is no longer in use, and that you should
>> instead upgrade the GRUB 2 images on these disks and finish the conversion
>> to GRUB 2 by removing old GRUB Legacy files. If you do not upgrade these
>> GRUB 2 images, then they may be incompatible with the new packages and
>> cause your system to stop booting properly.
>> .
>> You should generally finish the conversion to GRUB 2 unless these boot
>> records were created by a GRUB 2 installation on some other operating
>> system.
>
> A (1), but I won't touch the (2)s.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: templates.in
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20101207/8d701b6b/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: grub-pc.templates.in
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20101207/8d701b6b/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20101207/8d701b6b/attachment.pgp>
More information about the Pkg-grub-devel
mailing list