Control: retitle -1 grub-common: POTFILES-shell.in is not read when generating grub.pot
Hi, I took some time looking into this bug. It seems that strings from files listed in po/POTFILES-shell.in are not included in the generated grub.pot file. Relevant commands in the build log are: case `/usr/bin/xgettext --version | sed 1q | sed -e 's,^[^0-9]*,,'` in \ '' | 0.[0-9] | 0.[0-9].* | 0.1[0-5] | 0.1[0-5].* | 0.16 | 0.16.[0-1]*) \ /usr/bin/xgettext --default-domain=grub --directory=../../.. \ --add-comments=TRANSLATORS: --keyword=_ --keyword=N_ --flag=_:1:pass-c-format --flag=N_:1:pass-c-format --flag=error:3:c-format --flag=error_at_line:5:c-format --from-code=UTF-8 ${end_of_xgettext_options+} --flag=argp_error:2:c-format --flag=argp_failure:4:c-format --flag=error:3:c-format --flag=error_at_line:5:c-format \ --files-from=../../../po/POTFILES.in \ --copyright-holder='Free Software Foundation, Inc.' \ --msgid-bugs-address="$msgid_bugs_address" \ ;; \ *) \ /usr/bin/xgettext --default-domain=grub --directory=../../.. \ --add-comments=TRANSLATORS: --keyword=_ --keyword=N_ --flag=_:1:pass-c-format --flag=N_:1:pass-c-format --flag=error:3:c-format --flag=error_at_line:5:c-format --from-code=UTF-8 ${end_of_xgettext_options+} --flag=argp_error:2:c-format --flag=argp_failure:4:c-format --flag=error:3:c-format --flag=error_at_line:5:c-format \ --files-from=../../../po/POTFILES.in \ --copyright-holder='Free Software Foundation, Inc.' \ --package-name="${package_gnu}grub" \ --package-version='2.06' \ --msgid-bugs-address="$msgid_bugs_address" \ ;; \ esac There should be some other xgettext invocations to include strings in POTFILES-shell.in, using the option --files-from=../../../po/POTFILES-shell.in. See the corresponding commands in po/Makefile.in.in in the source code tree. After building the package, the commands to include strings in POTFILES-shell.in are present in the backup file Makefile.in.in~, but not in the regenerated Makefile.in.in. Note that po/gettext-patches/0001-Support-POTFILES-shell.patch will fix the Makefile. So it's likely that these gettext patches are erroneously not applied.