moparisthebest/pacman
1
0
Fork 0
mirror of https://github.com/moparisthebest/pacman synced 2024-11-10 03:25:01 -05:00
Code Issues Releases Wiki Activity
cfb86fed7c
pacman/lib/libalpm/po/Makevars

27 lines
946 B
Plaintext
Raw Normal View History

i18n stuff
2006-06-28 01:37:15 -04:00
# Makefile variables for PO directory in any package using GNU gettext.
# Usually the message domain is the same as the package name.
DOMAIN = libalpm
# These two variables depend on the location of this directory.
subdir = po
top_builddir = ../../../
# These options get passed to xgettext.
Disable the line number in .po files. 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>
2008-03-03 15:32:54 -05:00
XGETTEXT_OPTIONS = --no-location \
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>
2008-02-25 15:52:53 -05:00
--keyword=_ --flag=_:1:c-format \
--keyword=N_ --flag=N_:1:c-format
i18n stuff
2006-06-28 01:37:15 -04:00
# This is the copyright holder that gets inserted into the header of the
# $(DOMAIN).pot file. Set this to the copyright holder of the surrounding
* Update of all the *.po files and *.pot template files. * Makefile targets to rebuild po files now work - use 'make update-po' in the po directories. * Added two new translation templates as requested on the ML- 'it' and 'pt_BR'. This commit might be a bit big for the mailing list to like on the commit message. :)
2007-02-06 21:22:53 -05:00
# package.
Update copyrights in gettext files
2009-07-27 22:40:43 -04:00
COPYRIGHT_HOLDER = Pacman Development Team <pacman-dev@archlinux.org>
i18n stuff
2006-06-28 01:37:15 -04:00
# This is the email address or URL to which the translators shall report
* Update of all the *.po files and *.pot template files. * Makefile targets to rebuild po files now work - use 'make update-po' in the po directories. * Added two new translation templates as requested on the ML- 'it' and 'pt_BR'. This commit might be a bit big for the mailing list to like on the commit message. :)
2007-02-06 21:22:53 -05:00
# bugs in the untranslated strings.
MSGID_BUGS_ADDRESS = pacman-dev@archlinux.org
i18n stuff
2006-06-28 01:37:15 -04:00
# This is the list of locale categories, beyond LC_MESSAGES, for which the
# message catalogs shall be used. It is usually empty.
EXTRA_LOCALE_CATEGORIES =
Reference in New Issue Copy Permalink