diff options
author | Chantry Xavier <shiningxc@gmail.com> | 2008-02-25 21:52:53 +0100 |
---|---|---|
committer | Dan McGee <dan@archlinux.org> | 2008-02-25 20:25:57 -0600 |
commit | 7eaad2f2a9879499d29e20bb897b018f0b13f6c1 (patch) | |
tree | 78734ddf940301c349b4a0296e47a4f612c748ae /lib/libalpm/po/pl.po | |
parent | c23ecc6160749e635767cdfbd23760e9e809c949 (diff) | |
download | pacman-7eaad2f2a9879499d29e20bb897b018f0b13f6c1.tar.xz |
xgettext : change pass-c-format flag to c-format.
Currently xgettext apparently attempts to autodetect c format strings (eg a
string with a %s) to decide whether to use c-format flag or not.
If we use --flag=_:1:c-format instead of --flag=_:1:pass-c-format, the
c-format will be applied everywhere.
I couldn't find this documented anywhere though. But the pass prefix is
mentioned here :
http://www.gnu.org/software/gettext/manual/html_node/xgettext-Invocation.html#xgettext-Invocation
"Specifies additional flags for strings occurring as part of the argth
argument of the function word. The possible flags are the possible format
string indicators, such as ‘c-format’, and their negations, such as
‘no-c-format’, possibly prefixed with ‘pass-’."
And c-format is documented there :
http://www.gnu.org/software/gettext/manual/html_node/c_002dformat-Flag.html#c_002dformat-Flag
"This situation happens quite often. The printf function is often called
with strings which do not contain a format specifier. Of course one would
normally use fputs but it does happen. In this case xgettext does not
recognize this as a format string but what happens if the translation
introduces a valid format specifier? The printf function will try to access
one of the parameters but none exists because the original code does not
pass any parameters."
And that's exactly what happened with FS#9658.
So using c-format for every string will prevent this issue from happening
again.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
Diffstat (limited to 'lib/libalpm/po/pl.po')
0 files changed, 0 insertions, 0 deletions