Launchpad itself

error in translation error-checking

Asked by Benjamin Geer

I'm translating the Transmission Bittorrent client into Arabic, and I've encountered a bug in the mechanism that checks for errors in translations. The problem occurs in the translation of message 77:

English singular:
%1$'d Piece @ %2$s
English plural:
%1$'d Pieces @ %2$s

"msgstr[0]' is not a valid C format string, unlike 'msgid'. Reason: The string refers to argument number 2 but ignores argument number 1."

This is incorrect, because in Arabic, ignoring argument 1 in the translation is often the right thing to do. If the value of the argument is 0, 1 or 2 (as determined by the gettext plural expression), the translation should reflect this value in the form of the Arabic word for "piece", rather than by including the number itself in the translation; therefore the translation will not refer to the argument. There's an example here (in Arabic) on the Arabeyes project Wiki: http://tinyurl.com/4dweuj

As a workaround, I've included argument 1 in parentheses in the translation, but this is a hack, because it has no reason to be there. The error-checking mechanism should be fixed so that it accepts translations that don't refer to all the arguments.

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Benjamin Geer
Solved:
Last query:
Last reply:
Revision history for this message
Benjamin Geer (benjamin-geer) said : 		#1

I'm guessing that error-checking is being done with "msgfmt -c"; the bug seems to be in msgfmt. I suggest dropping the "-c" option and replacing it with "--check-header --check-domain".

Revision history for this message
Jeroen T. Vermeulen (jtv) said : 		#2

Benjamin, your guess is almost right. This code is not coming from our own code, and I'm not sure we should try to fix it on our end if gettext itself is likely to consider at an error as well.

Revision history for this message
Benjamin Geer (benjamin-geer) said : 		#3

I've reported it as a bug in gettext:

https://savannah.gnu.org/bugs/index.php?23183

However, gettext *can* accept and use the desired translation, as long as the "-c" option is not passed to msgfmt. I've just tested this by putting the desired translation directly into the .po file and rebuilding Transmission, and gettext accepted it with no errors, because Transmission's build mechanism uses "msgfmt" without the "-c" option. Moreover, the desired translation works fine at run time.

Therefore, I still think it would be a good workaround for Launchpad not to use the "-c" option either, at least until this bug is fixed in gettext.

Revision history for this message
Benjamin Geer (benjamin-geer) said : 		#4

According to the gettext maintainer, gettext can't be made to work the way I'm suggesting, and the only solution is to have the programmer re-order the arguments in the source code:

http://savannah.gnu.org/bugs/?23183

So Launchpad should keep "msgfmt -c".