Re: Bug#258327: xgettext seems to overquote sh strings

[Santiago Vila <sanvila@unex.es>]

On Fri, 9 Jul 2004, Denis Barbier wrote:

> On Thu, Jul 08, 2004 at 02:47:10PM -0700, Martin Quinson wrote:
> > Package: gettext
> > Version: 0.14.1-2
> > Severity: normal
> >
> > Hi there,
> >
> > When asked to extract the following line:
> > INVALID_BASENAME=$(gettext 'Invalid basename: %s.\n')
> >
> > xgettext produce the following entry in the pot:
> > #: util/orphaner.sh:47
> > #, sh-format
> > msgid "Invalid basename: %s.\\n"
> > msgstr ""
> >
> > It looks like there is a \ too much. This is at least disorienting for
> > translators. Why should it be treated different from the C equivalent?
>
> Hi Martin,
>
> In C, '\n' is the ASCII character 0x0a, whereas it is interpreted as
> 0x5c 0x6e by shells.  Some applications may interpret C escapes, but
> one should not rely on it.  Gettext documentation tells that newlines
> should be added with an extra echo without argument, e.g.
>    gettext 'Hello, world.'
>    echo

Indeed, I quote from the manual:

  5. For each translatable string, change the output command `echo' or
     `$echo' to `gettext' (if the string contains no references to
     shell variables) or to `eval_gettext' (if it refers to shell
     variables), followed by a no-argument `echo' command (to account
     for the terminating newline). Similarly, for cases with plural
     handling, replace a conditional `echo' command with an invocation
     of `ngettext' or `eval_ngettext', followed by a no-argument `echo'
     command.


Think about this: gettext 'string' is similar to echo -n 'string', so if
echo 'Hello\n' does not interpret the \n, why should gettext 'Hello\n'?

May I close this bug?