On Wed, May 24, 2017 at 8:27 AM, adrian15 adrian15
<adrian15...@gmail.com> wrote:
> Hi Pol,
>
> I think we already do this in Super Grub2 Disk (
> https://github.com/supergrub/supergrub ) .
>
> I did not implement the translation system myself so I don't know how
> exactly you would apply to a bare GNU/Grub system. Our translation
> documentation is here:
> https://github.com/supergrub/supergrub/blob/master/TRANSLATION .
> As far as I understand GNU/GRUB supports the use of PO files and by using
> $"some text" you make that text translatable depending on the $lang variable
> value.
>
> Probably the GNU/GRUB documentation has a chapter on menues translation too.
Indeed, Super GRUB2 Disk allows you to change language at the main
menu and have all menus, and messages from grub, be translated into
the chosen language. I implemented this support and would be happy to
help you implement the same for upstream grub. SG2D uses unpatched
upstream grub (at least last I checked) and so the infrastructure is
already there. In fact, to get all of grub's interface other than the
menu to be translated all you need to do is change the $lang
environment variable.
I haven't looked at this for years and I don't have time to check the
code at the moment, but from memory here are the areas that need
changing to be able to select a language at the grub menu:
1: Right now translation of menuentries is done at grub-mkconfig time
rather than boot time. All other messages (like error messages, the
text above and below the menu, etc) are actually already translated at
boot time using gettext. grub-script (the language grub.cfgs are
written in) supports gettext as well, though currently that support is
not used with the grub-mkconfig generated grub.cfg. The support for
gettext in grub-script is used with the $"Some string to translate
here" syntax. For example as long as the Spanish locale (stored in
es.mo) has the string "Enable GRUB2's LVM support" translated then the
following code:
echo $"Enable GRUB2's LVM support"
Will print "Activa soporte LVM de GRUB2"
(Which is an example menuentry title from Super GRUB2 Disk.)
This is the same syntax supported by bash, but most people
(rightfully) don't use it due to security issues. grub-script's
implementation was made to avoid those security problems by (possibly
among other things) limiting it so that the only variables that can be
expanded from the translated string (msgstr) are variables that are
included in the string found in the source code (msgid).
So "all" you need to do, is replace the areas of grub-mkconfig that
spit out menuentry titles (and the few strings echoed in the grub.cfg)
so that rather than using gettext and expanding variable in
/etc/grub.d/10_linux variables to output a grub.cfg entry like:
menuentry "Debian GNU/Linux mit Linux 4.11" { ...
You would make grub-mkconfig output a set of lines like:
grub_distributor="Debian"
linux_version="4.11"
menuentry $"$grub_distributor GNU/Linux with Linux $linux_version" { ...
Which, with lang=de, would show "Debian GNU/Linux mit Linux 4.11" in
the grub menu, and with lang=es might show "Debian GNU/Linux con Linux
4.11".
Major obstacles I foresee in this are
1: This will be yet another layer of shell quoting within shell
quoting from grub-mkconfig. This will have readability, stability
(things shouldn't break when an msgstr includes a quotation mark) and
security implications. We've had multiple problems related to properly
escaping quotes in translations in grub-mkconfig in the past. Let's
try not to repeat that mistake again.
2: Readability of the grub.cfg. I think that we can all agree that
menuentry $"$grub_distributor GNU/Linux with Linux $linux_version" is
not fun to read. grub-mkconfig already creates a grub.cfg that is very
intimidating and hard to understand for grub users. I think the long
complicated grub.cfgs created by grub-mkconfig are a large part of why
people think that grub is "too complicated". I hope that there is some
way to achieve translation at boot time without making the situation
of grub.cfg readability much worse than it already is.
3: In my above example I added two variables, $grub_distributor and
$linux_version. We're likely going to need to have a discussion about
namespacing variables used in the grub.cfg so that we don't get
conflicts with people's additions in places like custom.cfg. Also, you
should be on the lookout for security implications of expanding
variables even if you do get all of the quoting correct in the
grub-mkconfig step.
4: menuentry creates a new context for environment variables, similar
to a subshell / subprocess in bash. That means that if you want to
change $lang in a menuentry, the following will alone will *not* work:
lang=en
menuentry "Español" {
lang=es
}
because your menuentry will create a new context with a *copy* of
$lang, will change that copy, then will exit destroying the changed
copy and leaving you back with $lang having a value of "en". Super
GRUB2 Disk works around this by using configfile within the menuentry
to re-load the grub.cfg within the new context. This means that if you
change languages 20 times you will be 21 layers deep in submenus and
contexts (which users will only notice if they press escape to go to
the previous menu, or possibly cause an overflow if they're really
ambitious). I figured that was good enough for SG2D, but it's probably
not good enough for upstream grub. Now that I've said all that, it
looks like $lang may be special in this regard since quick test showed
that such a menuentry actually *did* successfully change the language
used for grub's interface. This may be a bug, or may be me
misunderstanding something.
5: Even if the above weren't the case, I can't see how re-executing
the grub.cfg after a language change can be avoided since you need to
re-run each menuentry command such that the title will expand to the
new different translation.
I don't have a lot of free time at the moment (I shouldn't have spent
it on this message in the first place to be honest) but I'll try to
help when I can and if you want to take code from Super GRUB2 Disk
that I wrote I am willing to say that my copyright assignment to grub
covers that code as well. That said 1: I Am Not A Lawer, 2: Do *not*
copy any code from SG2D or anywhere else without clearly stating where
it came from when you submit it to grub.
I hope that helps and I really hope you're able to add this feature!
--
Jordan Uggla (Jordan_U on irc.freenode.net)
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
