(gettext.info)Interpolation I


Next: Interpolation II Prev: Quote-like Expressions Up: Perl
Enter node , (file) or (file)node

15.5.18.5 Invalid Uses Of String Interpolation
..............................................

   Perl is capable of interpolating variables into strings.  This offers
some nice features in localized programs but can also lead to problems.

   A common error is a construct like the following:

     print gettext "This is the program $0!\n";

   Perl will interpolate at runtime the value of the variable ‘$0’ into
the argument of the ‘gettext()’ function.  Hence, this argument is not a
string constant but a variable argument (‘$0’ is a global variable that
holds the name of the Perl script being executed).  The interpolation is
performed by Perl before the string argument is passed to ‘gettext()’
and will therefore depend on the name of the script which can only be
determined at runtime.  Consequently, it is almost impossible that a
translation can be looked up at runtime (except if, by accident, the
interpolated string is found in the message catalog).

   The ‘xgettext’ program will therefore terminate parsing with a fatal
error if it encounters a variable inside of an extracted string.  In
general, this will happen for all kinds of string interpolations that
cannot be safely performed at compile time.  If you absolutely know what
you are doing, you can always circumvent this behavior:

     my $know_what_i_am_doing = "This is program $0!\n";
     print gettext $know_what_i_am_doing;

   Since the parser only recognizes strings and quote-like expressions,
but not variables or other terms, the above construct will be accepted.
You will have to find another way, however, to let your original string
make it into your message catalog.

   If invoked with the option ‘--extract-all’, resp.  ‘-a’, variable
interpolation will be accepted.  Rationale: You will generally use this
option in order to prepare your sources for internationalization.

   Please see the manual page ‘man perlop’ for details of strings and
quote-like expressions that are subject to interpolation and those that
are not.  Safe interpolations (that will not lead to a fatal error) are:

   • the escape sequences ‘\t’ (tab, HT, TAB), ‘\n’ (newline, NL), ‘\r’
     (return, CR), ‘\f’ (form feed, FF), ‘\b’ (backspace, BS), ‘\a’
     (alarm, bell, BEL), and ‘\e’ (escape, ESC).

   • octal chars, like ‘\033’
     Note that octal escapes in the range of 400-777 are translated into
     a UTF-8 representation, regardless of the presence of the ‘use
     utf8’ pragma.

   • hex chars, like ‘\x1b’

   • wide hex chars, like ‘\x{263a}’
     Note that this escape is translated into a UTF-8 representation,
     regardless of the presence of the ‘use utf8’ pragma.

   • control chars, like ‘\c[’ (CTRL-[)

   • named Unicode chars, like ‘\N{LATIN CAPITAL LETTER C WITH CEDILLA}’

     Note that this escape is translated into a UTF-8 representation,
     regardless of the presence of the ‘use utf8’ pragma.

   The following escapes are considered partially safe:

   • ‘\l’ lowercase next char

   • ‘\u’ uppercase next char

   • ‘\L’ lowercase till \E

   • ‘\U’ uppercase till \E

   • ‘\E’ end case modification

   • ‘\Q’ quote non-word characters till \E

   These escapes are only considered safe if the string consists of
ASCII characters only.  Translation of characters outside the range
defined by ASCII is locale-dependent and can actually only be performed
at runtime; ‘xgettext’ doesn’t do these locale-dependent translations at
extraction time.

   Except for the modifier ‘\Q’, these translations, albeit valid, are
generally useless and only obfuscate your sources.  If a translation can
be safely performed at compile time you can just as well write what you
mean.


automatically generated by info2www version 1.2.2.9