Using c-format on every strings allowed me two found two broken ones.
One was harmless, but the other caused a segfault, as reported in FS#9658.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
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>
For our Czech, Polish, and Russian translations, they do not need to be at
the more specific 'lang_COUNTRY' code, but can live at just plain 'lang'.
This follows the pattern of most other translated programs out there as
Roman pointed out on IRC.
ru_RU: 2 (pacman and libalpm)
ru: 128 for him, 131 for me (everything else)
Signed-off-by: Dan McGee <dan@archlinux.org>
Move these two scripts into contrib/, and start the process of de-automaking
them by removing the @sysconfdir@ references and the gettext initialization.
The removal of all gettext will soon follow.
Signed-off-by: Dan McGee <dan@archlinux.org>
We are in string freeze for the 3.1.1 release. This commit updates all the
message files to the latest code, and all translation updates should be
based off of these po-files. Please attempt to keep the line number changes
to a minimum- there should be no reason to update these po files with just
new line numbers. That way we can more easily see exactly which translations
were updated.
Signed-off-by: Dan McGee <dan@archlinux.org>
It's probably far from perfect, but at least I tried to translate
everything.
I noticed a missing newline at libalpm/trans.c , line 573 :
_alpm_log(PM_LOG_ERROR, _("call to popen failed (%s)"),
I don't think it's possible to fix it now (string freeze?), so I didn't.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
abs has always been an Arch Linux specific tool, and although it is used
primarily by pacman and makepkg, it should not be included with a distro-
agnostic tarball. In addition, maintenance of the script would be better
outside of pacman and would allow for more frequent updates.
This also facilitates our move away from a cvsup/csup dependent tool for
syncing PKGBUILDs.
Signed-off-by: Dan McGee <dan@archlinux.org>
Only the messages in pacman frontend were updated, and it's probably not
perfect yet, but it's a start.
There are 160 untranslated msg left for the scripts / tools.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
* Updated libalpm translation
* Regenerated hu.po files, because the 'call-for-translators version' was outdated
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu>
Signed-off-by: Dan McGee <dan@archlinux.org>
