Change the pacman_upgrade stub function to do what pacman_add used to do so
we can eliminate pacman_add. Move the code to the more-descriptive name of
upgrade.c.
Note that we have made no changes to the backend libalpm, where an ADD type
transaction could still be supported.
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>
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>
