patch, 2 partsi18n: Extract msgs marked by sh gettext wrappers

Since we have additional shell wrappers (gettextln and eval_gettextln) for gettext, we need to take into account these wrapers when run 'make pot' to extract messages from shell scripts.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
---
 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

In commit b9b9c22, Ævar addressed a issue when gettextized a message started with "--", such as "--cached cannot be used with --files", the first word in the message would be treated as an option of gettext, and might raise a bad option error.

The solution Ævar provided is to add a extra "--" option between gettext and the message. But Vincent fount out later that the extra "--" was extracted as gettext message by xgettext instead of the real message. See:

 * http://thread.gmane.org/gmane.comp.version-control.git/199042

In order to fix this dilemma, we move the extra "--" option from gettext to gettext wrapper (gettextln, and eval_gettext), and gettextize the message using the wrapper function instead of gettext itself.

But for system with libintl's gettext.sh, eval_gettext and eval_gettextln won't have this fix.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
 git-sh-i18n.sh   | 8 ++++++--
 git-submodule.sh | 2 +-
 2 files changed, 7 insertions(+), 3 deletions(-)

On Mon, Jun 4, 2012 at 1:09 AM, Jiang Xin <worldhello.net@gmail.com> wrote:

I think a better solution to this is to just apply this patch:

-               die "$(gettext -- "--cached cannot be used with --files")"
+               die "$(gettext "the --cached option is incompatible
with the --files option")"

It's one message only, and this is due to a bug in the xgettext extraction. I think changing the only message suffering from this issue (or likely to suffer from it) beats a solution where starting a message with -- only works for some of the xgettext commands/functions.

2012/6/4 Ævar Arnfjörð Bjarmason <avarab@gmail.com>:

The rewrite message is a bit odd for there are 40 more alike messages (extracted from C files) start with "--”, such as:

    msgid "--delete only accepts plain target ref names"
    msgid "--all and --tags are incompatible"
    msgid "--all can't be combined with refspecs"
    msgid "--mirror and --tags are incompatible"
    msgid "--mirror can't be combined with refspecs"

If I had not changed like this, I would not find out there are 27 marked messages (by gettext wrappers) have not been extracted to "po/git.pot". ;-)

Jiang Xin <worldhello.net@gmail.com> writes:

I think there is value for having a generic solution than declaring "No message shall begin with a dash".

I am not convinced that it is ideal for the implementation of gettext_ln to prepend "--" in front when it calls gettext, though. Shouldn't the caller of gettext_ln be the one who is responsible for doing that? After all, that is the one that knows that the MSGID argument needs the quoting.

2012/6/5 Junio C Hamano <gitster@pobox.com>:

I saw Ævar's bug report on xgettext to the GNU gettext list:

 * http://git.661346.n2.nabble.com/GETTEXT-BUG-xgettext-1-can-t-extract-quot-gettext-foo-quot-td7560744.html

May be post to a more official mailing list, such as bug-gnu-utils at https://lists.gnu.org/mailman/listinfo/bug-gnu-utils will get some response, but I doubt there won't be a clear resolution in xgettext.

The default configurations of xgettext for shell scripts are defined in file 'gettext-tools/src/x-sh.c':

      x_sh_keyword ("gettext");
      x_sh_keyword ("ngettext:1,2");
      x_sh_keyword ("eval_gettext");
      x_sh_keyword ("eval_ngettext:1,2");

Keyword "gettext" above is the same as "gettext:1". xgettext has no idea of options and arguments, if there is a seperator ('--') between gettext and the message, message is argument 2. For example:

    gettext -- "--cached cannot be used with --files"

We can override the default settings of xgettext by passing '-k' and multiple '--keyword', '--flags' options to xgettext.

    xgettext  ... --language=Shell \
                  -k  --keyword=gettext:2 \
                  --flag=gettext:2:pass-sh-format  ...

But "gettext message" will be broken.

Write a wrapper for gettext and extract messages using 'xgettext --keyword=<gettext-wrapper>' is a reasonable solution.

Jiang Xin wrote:

I think bug-gettext is the right place: http://lists.gnu.org/archive/html/bug-gettext/2012-06/msg00003.html

The double negative is leaving me confused. :) Are you saying you doubt that anyone will come up with a patch to fix xgettext, or that you doubt that the result will be satisfactory?

[...]

For what it's worth that does seem to me like the most sensible workaround in the short term. :/

	gittext () {	# or sane_gettext or literal_gettext or something
		gettext -- "$1"
	}

	gittextln () {
		gettext -- "$1"
		echo
	}

Thanks, Jonathan

Jonathan Nieder <jrnieder@gmail.com> writes:

Thanks for rephrasing ;-) That "g*I*ttext" looks a bit too cute for my taste, but something along that line does seem to be a reasonable way forward.