From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30684 invoked by alias); 25 Jan 2018 01:47:18 -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 30673 invoked by uid 89); 25 Jan 2018 01:47:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=month, day X-HELO: mail-qt0-f182.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=tZCiDX5r582Q8/9GMafLXagfwnDEXqcqNDXBvjK9qUM=; b=p73pqPy2aU0yZHOS/VS05rWE+uc085I1WEzJ0ksLwfe4NqzJzAVLF3esT5YlQuwrwh OfAzPurl/mYOzh8QOSa+9ituzAL5C1w4L4dEvskjhDoZqGTiqKs55bb9vgyCrmPNVfJi ybDaJb4Th1CUrcgne6g6JHaHbvM9nr09w5A5Wh1t/BbO0ARrxQiMSN91PjxgxJt3sHbq K+yhdeJwVrTPDt4gyXDt+IBYq4jV0aicGyXovxEMfEjhF5vw2jgiZc3Y+At7yDpSbTtx WPsbwJE/y9njipFt6F4nGjrCabP4La7IiGhjwgeC/L0D/wgrGkbvzYFwTnqqq1k2P327 xyow== X-Gm-Message-State: AKwxytcIf2JitpsbVy/hMXbj4/CZIus8fNVKVVoHkEd6sSOV1b3bNXca aC7W4ksQ3z6csh7/xzo7RX+eBfuDzvU= X-Google-Smtp-Source: AH8x224FQKP3LzOs6f+o3ox39IQxudM6rf+XA9IkJCSs046UwkSbeCS1JLWTEWe23gMJcjGsIug/WA== X-Received: by 10.200.1.82 with SMTP id f18mr14181799qtg.51.1516844834431; Wed, 24 Jan 2018 17:47:14 -0800 (PST) Subject: Re: [PATCH v12 5/6] Documentation to the above changes (bug 10871). To: Rafal Luzynski , libc-alpha@sourceware.org References: <1802414843.37687.1515744747279@poczta.nazwa.pl> <1927758682.38060.1515745107778@poczta.nazwa.pl> <49ea50a9-3cca-bbfe-8c75-41ea603d1a58@pacific.net> <232736801.586762.1516016805848@poczta.nazwa.pl> <1451718525.153086.1516445418821@poczta.nazwa.pl> <1069394619.57314.1516610620585@poczta.nazwa.pl> <1090774665.1268651.1516745363342@poczta.nazwa.pl> <2074921143.499812.1516841147600@poczta.nazwa.pl> From: Carlos O'Donell Message-ID: <3bc43235-8938-980c-4354-019969cc9cc8@redhat.com> Date: Thu, 25 Jan 2018 01:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <2074921143.499812.1516841147600@poczta.nazwa.pl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-01/txt/msg00778.txt.bz2 On 01/24/2018 04:45 PM, Rafal Luzynski wrote: > I have received a comment from Gnulib maintainers that this > documentation is too ambiguous because does not define which > date format should be considered "full" and which should be > considered "month standalone". I have explained that the date > is "full" if there is a day number and a month name (the week > day and the year number are optional) and the month name is > "standalone" when there is no day number (it may be just the > month name alone, or if a year number is added this still counts > as standalone). It has been requested to add this definition > to the glibc documentation. > > But, OTOH, I can't guarantee this works the same in all languages > which have this issue. Maybe we should add a phrase "in many > languages" or "in most of the languages which need this feature"? > > Any suggestions how to fix the documentation? Does anybody want > to commit immediately? I see no immediate need to rush into documenting this any more than is currently documented. Please reflect on the comments provided by the gnulib maintainers and see if any ideas come to mind. In my experience it is sometimes best to use examples here to define what you mean. So instead of writing completely generic text, we use Polish as an example and describe which is full and standalone using the example. -- Cheers, Carlos.