From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-82222-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 124782 invoked by alias); 19 Jul 2017 07:15:49 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 121347 invoked by uid 89); 19 Jul 2017 07:15:42 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=HTo:D*ucla.edu, Hx-languages-length:1262
X-HELO: homiemail-a52.g.dreamhost.com
Subject: Re: libc-2.25.90.pot
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
 libc-alpha@sourceware.org, Paul Eggert <eggert@cs.ucla.edu>,
 Benno Schulenberg <coordinator@translationproject.org>
References: <8b9b4e60-f580-e56a-26bc-adb7192ba779@sourceware.org>
 <6e7f7602-3536-2edb-0cf4-e66a948fdb71@translationproject.org>
 <f0feca6f-c7f4-6a48-c8dc-cbe6cd4dd7ca@translationproject.org>
 <c45da7e9-32f9-4b9c-740b-2a3a2d3e3fe0@linaro.org>
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
Message-ID: <dbf8693c-47fa-a025-f854-6e0bb3515666@gotplt.org>
Date: Wed, 19 Jul 2017 07:15: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: <c45da7e9-32f9-4b9c-740b-2a3a2d3e3fe0@linaro.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2017-07/txt/msg00666.txt.bz2

On Wednesday 19 July 2017 12:32 AM, Adhemerval Zanella wrote:
> 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?

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.

Siddhesh