grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] suppress error message "/grub2/locale/en.mo.gz not found"


From: Mads Kiilerich
Subject: Re: [PATCH] suppress error message "/grub2/locale/en.mo.gz not found"
Date: Mon, 24 Sep 2012 11:37:12 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120828 Thunderbird/15.0

On 09/24/2012 08:51 AM, Michael Chang wrote:
We don't insert gettext module if message catalog file missing to
prevent error message from being logged.

Signed-off-by: Michael Chang <address@hidden>
---
  util/grub.d/00_header.in |   10 +++++++---
  1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/util/grub.d/00_header.in b/util/grub.d/00_header.in
index bb34ef2..d438d52 100644
--- a/util/grub.d/00_header.in
+++ b/util/grub.d/00_header.in
@@ -182,10 +182,14 @@ EOF
# Gettext variables and module
  if [ "x${LANG}" != "xC" ] ; then

Couldn't / sholdn't this check be replaced by the new check you introduce?

+# We don't insert gettext module if message catalog file missing
+# To prevent error message from being logged (bnc#771393)

That seems like a reference to some (internal Suse?) bugtracker? To me it is https://bugzilla.redhat.com/show_bug.cgi?id=817187 , but I guess https://savannah.gnu.org/bugs/?35880 is the best reference.

    cat << EOF
-  set locale_dir=\$prefix/locale
-  set lang=${grub_lang}
-  insmod gettext
+  if [ -f "\$prefix/locale/${grub_lang}.mo" ] ; then
+    set locale_dir=\$prefix/locale
+    set lang=${grub_lang}
+    insmod gettext
+  fi
  EOF
  fi

I'm +1 for the principle, but does it really work for real world locales like de_DE which will use de.mo on runtime?

I would guess that it also should handle all the logic in gettext.c grub_gettext_init_ext() and grub_mofile_open_lang() and how these functions are invoked: .gz extension, _CC stripping and primary/secondary locale_dir.

(I would prefer if all this processing could be done in mkconfig instead of on runtime, but I guess the desire for backward compatibility prevents that.)

(It also seems to me like the current system lacks support for fallback from address@hidden to ll_CC and ll. I don't know if that is a real problem.)

/Mads



reply via email to

[Prev in Thread] Current Thread [Next in Thread]