From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) by sourceware.org (Postfix) with ESMTPS id 50FB1385781B for ; Fri, 19 Nov 2021 14:48:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 50FB1385781B Received: by mail-qk1-f181.google.com with SMTP id i9so10389593qki.3 for ; Fri, 19 Nov 2021 06:48:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=m33vRvTWFw9O2in8ZfcQvEVpYhgKkJlOPlQREyggO4o=; b=Xe23+LpfAzrEMvi/iGE7LxqpOWePKg9gcRWkEgsuTW8Tfh3WC1JitziEnBZS/I+31C h6s6bvSHrdQIom/2Wx4WU7ToJEOF/sJ9OtdqDgG5WiWri8a43iivjMQDqHVDIMnxPibF 2qZMecsxRhLQ9kG89L7xqCMTGw6wdv0S8RKLHRsIBJvfz7JUhy8J4SbiCS5/xM07wVXx 0En2N2zGkEJmbiHF0TMAkZx8WXch8BEvO8ldbuSp9D0DKFrBvuLWJQleq8MKOD6ZswNs CfpWcQoyMgIUVORh+gwRvs75azbLTjFrCc/HwcSThazthZlZtHXjkVjHFXVvb3MDxyHa Rj2Q== X-Gm-Message-State: AOAM532zMGpzHUhkh+gp6VXKjGPCWOWsLtH32UNMjgrGM0gB+ZA96IAB 9EeJaSecfRAMXcRm1j0/IA4W1ZYrpAjgLSe0zsw= X-Google-Smtp-Source: ABdhPJw5tlYbcMAuxDl9QzCyU3tyTKHCu0xfnMWCr3NxYsoIxLBj2GA+xzoDIJoWroYxSPPyyL0QMTWveLYrqJia94c= X-Received: by 2002:a37:6316:: with SMTP id x22mr28008171qkb.239.1637333338684; Fri, 19 Nov 2021 06:48:58 -0800 (PST) MIME-Version: 1.0 References: <202105161001.AA00006@tamuki.linet.gr.jp> In-Reply-To: <202105161001.AA00006@tamuki.linet.gr.jp> From: Wei-Lun Chao Date: Fri, 19 Nov 2021 22:48:47 +0800 Message-ID: Subject: Re: [PATCH v2] localedata: Updates for Taiwanese locales [BZ #24409] To: TAMUKI Shoichi Cc: "Carlos O'Donell" , libc-alpha Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, BODY_8BITS, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2021 14:49:01 -0000 Dear Shoichi, Thanks for your explanation. I'll add this part of patch. TAMUKI Shoichi =E6=96=BC 2021=E5=B9=B45=E6=9C=8816=E6= =97=A5 =E9=80=B1=E6=97=A5 =E4=B8=8B=E5=8D=886:04=E5=AF=AB=E9=81=93=EF=BC=9A > > Hello Wei-Lun-san, > > From: Wei-Lun Chao > Subject: Re: [PATCH v2] localedata: Updates for Taiwanese locales [BZ #24= 409] > Date: Thu, 13 May 2021 13:10:12 +0800 > > > > > Changelog: > > > > * localedata/locales/cmn_TW: Header cleanup; Remove space (abmon); = Add > > > > (week); Change (thousands_sep); Simplify (yesexpr) and (noexpr). > > > > * localedata/locales/hak_TW: Likewise and add collation. > > > > * localedata/locales/nan_TW: Likewise and add collation. > > > > * localedata/locales/lzh_TW: Likewise and add collation. > > > > > > If elements from 0 to 59 are defined for alt_digits in lzh_TW, there > > > are the following problems: > > > > > > $ LANG=3Dlzh_TW date -d "1959-04-01 09:00:00" +"%Oy" > > > > > > $ LANG=3Dlzh_TW date -d "1960-04-01 09:00:00" +"%Oy" > > > 60 > > > > > > Up to 99 elements should be defined for alt_digits. > > > > First, alt_digits works like "alt_numbers". I don't know how to just > > map each digit to another character. > > Before this patch, alt_digits covers 0..31, and this patch covers > > 0..59. I am not sure, is it worthy to extend > > to 0..99, because those presentations are not suitable for year > > numbers. For example: > > $ LANG=3Dlzh_TW date -d "1959-04-01 09:00:00" +"%Oy" > > We will expect instead of > > I understand what you are concerned about. > > In Japan, for example, it is not sutable to use number names to > express another form of year notation using alternative numeric > symbols in years such as AD 1984 and AD 645. It is commonly expressed > in positional notation. I think the situation is the same in Taiwan. > > On the other hand, for example, it is not suitable to use positional > notation to express another form of year notation using alternative > numeric symbols in years such as AD 78. It is commonly expressed in > number names. Please see the attached file alt_digits.png. > > I think that these boundaries are empirically determined by whether > the numerical value is 2 digits or less or 3 digits or more. > Therefore, it makes sense to define alt_digits up to 99. > > Regards, > TAMUKI Shoichi