[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug-gettext] [bug #48411] xgettext does not detect conflicting plural f
From: |
Guido Flohr |
Subject: |
[bug-gettext] [bug #48411] xgettext does not detect conflicting plural forms |
Date: |
Tue, 5 Jul 2016 14:32:46 +0000 (UTC) |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0 |
URL:
<http://savannah.gnu.org/bugs/?48411>
Summary: xgettext does not detect conflicting plural forms
Project: GNU gettext
Submitted by: gflohr
Submitted on: Tue 05 Jul 2016 02:32:44 PM GMT
Category: None
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
_______________________________________________________
Details:
Run this piece of C code through xgettext:
printf(ngettext("One network.\n", "%s networks.\n", count), "Many");
printf(ngettext("One network.\n", "%lu networks.\n", count), count);
You will get one single po entry:
#: network.c:1 network.c:2
#, c-format
msgid "One network.\n"
msgid_plural "%s networks.\n"
msgstr[0] ""
msgstr[1] ""
In the example code this is likely to cause a segmentation fault. Yes, sure,
the example does not make a lot of sense but it is perfectly legal usage of
ngettext and illustrates the problem.
The best solution would probably be to use the combination of the singular and
plural message id as the key into the translation catalog. But that would not
be possible without changing the gmo format.
But xgettext should at least treat this situation as a fatal error condition.
In case somebody runs into this problem in a real-world application: Use
npgettext() instead of ngettext() and add a message context as a workaround!
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?48411>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [bug-gettext] [bug #48411] xgettext does not detect conflicting plural forms,
Guido Flohr <=