From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11655 invoked by alias); 19 Jul 2017 07:33:53 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 10700 invoked by uid 89); 19 Jul 2017 07:33:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=HTo:D*ucla.edu, poyarekar, Poyarekar, 19072017 X-HELO: mail-out-2.webreus.nl Subject: Re: libc-2.25.90.pot To: Siddhesh Poyarekar , Adhemerval Zanella , libc-alpha@sourceware.org, Paul Eggert References: <8b9b4e60-f580-e56a-26bc-adb7192ba779@sourceware.org> <6e7f7602-3536-2edb-0cf4-e66a948fdb71@translationproject.org> From: Benno Schulenberg Message-ID: Date: Wed, 19 Jul 2017 07:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-07/txt/msg00669.txt.bz2 Op 19-07-2017 om 09:15 schreef Siddhesh Poyarekar: > On Wednesday 19 July 2017 12:32 AM, Adhemerval Zanella wrote: >> >> 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? > > There are three of those instances and they refer to line numbers in the > timezone data file. If we can assume that the tzdata files are sane > then I suppose we could assume %d for these. Or at least change them to something that xgettext recognizes. There are several instances of % and % in the POT file, so xgettext is able to recognize some of those "PRI..." strings, but seemingly not custom-defined ones? Benno