Also fix a broken contrib/ Makefile, found with make distcheck. I also let
the little translation linebreak update slip in here as it was small enough
not to be a big deal, and this should just prevent it from happening again
later anyway.
Signed-off-by: Dan McGee <dan@archlinux.org>
Hopefully the last of the huge commits ever. This also adds the c-format tag
to all of the translated messages.
Signed-off-by: Dan McGee <dan@archlinux.org>
Add the --no-location xgettext option to disable the line numbers. They are
not very useful, and generate a huge number of pointless line changes on
every update.
Ref: http://www.archlinux.org/pipermail/pacman-dev/2008-March/011332.html
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
We only had one string change, and just a newline, so we can actually make
this update in its own commit rather than updating pacman.pot and making a
huge number of line changes, and then letting every translator do this
newline fix separately.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
The issue was discussed in this thread on the mailing list:
http://archlinux.org/pipermail/pacman-dev/2008-March/011324.html
In addition, the GNU gettext manual states that translation encoding is
completely separate from the encoding used by the users of the translation.
It makes sense for our project to use UTF-8 for all translations, regardless
of the preferred encoding used by users of a certain language. This allows
all contributors to more easily edit a translation file if necessary and not
have to worry about codepage issues.
Signed-off-by: Dan McGee <dan@archlinux.org>
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>
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>
