6. gdt さんの疑問 2008/7/18
We have 0.14.6 in pkgsrc, but gutenprint
requires 0.16. Can anyone shed light on if we
are behind, if 0.16 is bleeding edge, and if
there are reasons not to update?
05 44
7. joerg さんの答 2008/7/18
Ignoring pkgsrc for a moment -- what do you
want to do for NetBSD base?
Also keep in mind that the support for printf
argument reordering is missing in base and
therefore creates a lot of issues.
06 44
9. gdt さんの追試 2008/7/21
Thanks for pointing out that we should try it
Worked for me on 4_STABLE, current, and
failed on 3_STABLE.
08 44
10. wiz さんの提案 2008/11/11
Hi!
KDE and some Gnome packages are starting
to use newer features of gettext that are not
supported by the gettext version included in
NetBSD.
09 44
11. wiz さんの提案(2) 2008/11/11
IIRC, there was some work to improve
NetBSD's libintl support for these features,
but I haven't read news about this in a long
time.
10 44
12. wiz さんの提案(3) 2008/11/11
I suggest that we update the gettext in
pkgsrc and default to using the gettext from
pkgsrc on all pkgsrc platforms. When
NetBSD's builtin support gets good enough,
we can always switch back.
This would also allow us to get rid of the
msgfmtstrip hack
Comments? Other solutions? Status reports
about NetBSD's libintl?
11 44
13. joerg さんの答 2008/11/11
Who will fix the breakage on all NetBSD
versions that don't support positional
arguments in printf and friends?
12 44
14. dholland さんの追い打ち 2008/11/12
NetBSD has supported positional arguments
in printf for a good while.It's only scanf that's
an issue, and while I suppose that could turn
out to matter it seems moderately unlikely to.
13 44
20. adam さんの提案 2012/9/11
Greetings,
I have just updated mk/tools/msgfmt-
msgctxt.awk to make graphics/gimp compile
on systems where gettext-tools is not the
latest.
19 44
21. adam さんの提案(2) 2012/9/11
But I have a feeling this whole hack (see mk/
tools/msgfmt*) with msgfmt should be
removed and a proper dependency on devel/
gettext-tools>=0.18.1 settled in its place.
With the present setup it looks like not all
messages get translated.
Let's discuss the matter.
20 44
22. joerg さんの答 2012/9/11
It doesn't work, NetBSD's libintl doesn't
support the newer format.
21 44
29. 私の提案 2013/2/8
Hi,
Is it possible to change current strategy for
using gettext-{tools,lib}?
28 44
30. 私の提案(2) 2013/2/8
Current strategy
use builtin gettext-tools, or install devel/
gettext-tools (depend on settings and/or
builtin version)
1.
use builtin gettext-lib, or install devel/
gettext-lib (ditto)
2.
prepare *.po file depending on capabilities
of gettext-tools (strip some entries if it is
not supported)
3.
29 44
31. 私の提案(3) 2013/2/8
Issues - capability mismatch between
gettext-lib and gettext-tools
If gettext-tools is less capabilities than
gettext-lib,some translations may not appear
well even thoughits library has sufficient
capabilities.
If gettext-tools is much capabilities than
gettext-lib,some translations may not be
handled well by the old library.
30 44
32. 私の提案(2) 2013/2/8
It is not only happened with builtin one v.s.
pkgsrc one.
For example, NetBSD's Citrus libintl support
dcgettext(3) anddcngettext(3), but builtin
gettext-tools is too old and msgctxtwill be
stripped.
31 44
33. 私の提案(3) 2013/2/8
Proposed strategy
check capability of gettext-lib1.
if builtin gettext-tools is less capabilities
than -lib, -tools from pkgsrc must be
preferred than buitin one.
2.
prepare *.po file depending on capabilities
of gettext-lib (strip some entries if it is
not supported)
3.
32 44