[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 theuse 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 theuse 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 theuse 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.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on June 7, 2014 using texi2html 5.0.