This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: libc-2.25.90.pot
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org, Paul Eggert <eggert at cs dot ucla dot edu>, Benno Schulenberg <coordinator at translationproject dot org>
- Date: Tue, 18 Jul 2017 16:02:00 -0300
- Subject: Re: libc-2.25.90.pot
- Authentication-results: sourceware.org; auth=none
- References: <8b9b4e60-f580-e56a-26bc-adb7192ba779@sourceware.org> <6e7f7602-3536-2edb-0cf4-e66a948fdb71@translationproject.org> <f0feca6f-c7f4-6a48-c8dc-cbe6cd4dd7ca@translationproject.org>
On 18/07/2017 14:08, Benno Schulenberg wrote:
>
>>> The GNU C Library is about to release version 2.26.
>>>
>>> * Complete snapshot of 2.16 release containing `po/libc.pot':
>>> ftp://alpha.gnu.org/gnu/glibc/glibc-2.25-737-g66cd050.tar.bz2
>>
>> I see these changes when compared to the previous POT file:
>>
>> -msgid "\"%s\", line %d: "
>> +msgid "\"%s\", line %"
>>
>> -msgid " (rule from \"%s\", line %d)"
>> +msgid " (rule from \"%s\", line %"
>>
>> Are you sure these changes are intentional? If yes, then maybe
>> they could use a translator hint, to say what is coming after the
>> last "%"? Also, since those strings are not marked as c-format,
>> a malicious translator might be able to crash the relevant program
>> by putting in %tralala or something instead of %s?
>
> Ping?
>
> Benno
I think these a limitation of xgettext used to generate the pot files.
Both are similar defined:
timezone/zic.c
# msgid "\"%s\", line %"
487 fprintf(stderr, _("\"%s\", line %"PRIdLINENO": "), filename, linenum);
# msgid " (rule from \"%s\", line %"
490 fprintf(stderr, _(" (rule from \"%s\", line %"PRIdLINENO")")
And 'PRIdLINENO' is defined as
50 typedef intmax_t lineno;
51 #define PRIdLINENO PRIdMAX
Which means we will get different string encodings depending of how
__PRI64_PREFIX is defined by the ABI.
Both changes came from '92bd70fb' (Update timezone code from tzcode 2017b.) and
from original tz project it seems to get from cc8aec6ecb1ecc (zic: some
integer-width fixups). TZ commit log seems to indicate this is just a integer
cleanup without original from an actual bug or limitation.
Paul I think we can use default %d for ints for these two specific printf to
make translation work as intended. What do you think?