* Update all .po files because of the last "-q,--quiet" fix.
Also for some strange reason, en_GB was missing a few c-format tags.
* Finally, delete all unused translations.
Signed-off-by: Xavier Chantry <shiningxc@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
Two recent commits slightly broke the translations, so this fixes all of
them.
Signed-off-by: Xavier Chantry <shiningxc@gmail.com>
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>
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>
Remove what was a pretty weird abstraction in the libalpm backend. Instead
of parsing server URLs as we get them (of which we don't usually use more
than a handful anyway), wait until they are actually used, which allows us
to store them as a simple string list instead. This allows us to remove a
lot of code, and will greatly simplify the continuing refactoring of the
download code.
Signed-off-by: Dan McGee <dan@archlinux.org>
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>
* 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>
Update all of the pot and po files with the latest messages available.
Translators- you are encouraged to do this as well every time you update the
translation, and the directions in 'translation-help' should help. Also feel
free to delete all the old translations that end up at the bottom of these
files and only clutter things up.
Signed-off-by: Dan McGee <dan@archlinux.org>
This file only contained one private function : _alpm_db_whatprovides .
And the public alpm_db_whatprovides was in db.c , so I moved everything there.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
[Dan: updated POTFILES.in as well]
Signed-off-by: Dan McGee <dan@archlinux.org>
One string in de.po differed pretty strongly with its translated version.
It may still be totally wrong as far as translations go, but it compiles
now. Get translater to check.
Also, ensure the proper dbpath gets set in the db when it's created.
Signed-off-by: Travis Willard <travis@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
.gitignore works recursively, so we don't need Makefile and Makefile.in
in all of the subdirectory .gitignore files.
Signed-off-by: Dan McGee <dan@archlinux.org>
Remove versioncmp.c by moving all functions to locations that make sense.
Move replacement functions (for building without glibc) into util.c where
they belong, and do proper checks for them instead of using __sun__, etc.
Signed-off-by: Dan McGee <dan@archlinux.org>
Because of this commit:
ea1fef69ad
we lost a lot of gettext-ized messages on the libalpm side. Remove them
in order to clean out these files a bit.
Signed-off-by: Dan McGee <dan@archlinux.org>
In order to get more reliable message statistics, I updated all of the
po files by first doing a make *.pot-update followed by a make. I am
holding off on committing the pot files as this causes issues with make
constantly wanting to rebuild them.
Signed-off-by: Dan McGee <dan@archlinux.org>
* Move all .cvsignore files to .gitignore for switch in VCS. In addition,
delete ones that were unnecessary because they only contained Makefile
and Makefile.am.
Signed-off-by: Dan McGee <dan@archlinux.org>
work of fixing these in the translation files, and I removed a few fuzzys
while doing so. If any more patches for translations come, try to do it
against these files.
* Ran msgmerge on all po files from new pot files, but did not check in the
updated pot files as that just causes problems.
* Updated Italian translation
Giovanni Scafora <linuxmania@gmail.com>
* Updated Russian translation, added libalpm partial translation
Владимир Байраковский <4rayven@gmail.com>
* Updated Hungarian translation
Nagy Gabor <ngaba@petra.hos.u-szeged.hu>
* Updated French translation
solsTiCe d'Hiver <solstice.dhiver@laposte.net>
Thanks again guys!
Giovanni Scafora <linuxmania@gmail.com>
* long -> float conversion for package size output (which still may be the
wrong size, this needs to be looked at)
Translators and developers should count this as the string freeze unless
something REALLY essential comes up. Send in patches to these translations
when you get a chance (and patches are appreciated, as they are much easier
to deal with).
occasions where some alpm stuff could be used without initializing the
library (vercmp is one). TODO make these functions (handle accessors)
better by returning "library not initialized" instead of failing.
* Removed NoUpgrade lines from pacman.conf - we need to test this!
* Re-corrected the lib targets for src/util/*
* make dist seems to have updated the po files
Giovanni Scafora <linuxmania@gmail.com>
* added '-fstack-protector' flag to debug compile, to catch any buffer
overflows we may have in stack variables.
* Updated all of the language files, as the POT file was updated. NOTE FOR
TRANSLATORS, try to base your next contribution off of these, notice how
some msgids and messages have been wrapped to the next line- it makes it
easier to read anyway.
* More Makefile.am/configure.ac updates. 'make dist' and 'make distclean' now
work properly, with only one caveat- the automatic testing in distclean
doesn't do so hot as it is compiled with a default configure, which includes
the fakeroot-proof code (which does not cooperate with pactest).
* Added a Makefile.am for the pactest directory.
- the code should be clearer, more organized, commented, and have worthwhile
variable names now
- proactive backup=()s now work. That is, adding a file to a backup array
does what it should on the upgrade to that package, no longer forcing you to
wait a full upgrade cycle for it to take effect
* ldconfig was being run twice on an upgrade operation - fixed
* fixed another pm_fprintf/printf output corruption with the progress bars
* refactored some duplicate code for adjusting 'requiredby' lists
* Added config.rpath to .cvsignore
* Updated pot translation templates
* Located culprit of progress bar moving when unicode characters are used,
added a TODO note about it
* Removed '(target)' string from the sync.c error message, just like we did
from add.c yesterday
* Updated my TODO
unbelievable amount of strcmp() calls (25 million) due to the list searching.
This has been reimplemented with a set-intersection scheme, due to the fact
that file lists are always ordered. - NEEDS TESTING
* Minor clean up, "globalized" the str_cmp helper to match the alpm comparison
signature, so we can use it elsewhere.
