From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.2 required=3.0 tests=AWL,BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 16E161F466 for ; Mon, 20 Jan 2020 18:10:42 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=epyIE sSIOJAUExiBplsIVQzDlzxj1GLFnZljh2J89a1F0EOSQAnke3ckBVt8jxsF6sFI4 EDSFEPLhhQ9mNvgiUoC77LdVc63R01OgJTikLoFT5z4/ylw8AmKFLDkDGL8OFkNk iz84GLWbyB/ZMe6W6GtOe/Ke9X00w2hjRLNtw8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=MWDXMEYmrA8 U2WRvtxyJwNdAAbg=; b=bC5h0JtTc1vM6BGeg3nFcTXKvSkMoWl7yDx4acnA7rC /zp7AyjKRjowSbOg66jbaBhkL1dEcxqGzTjvoBi4H6AyfEFq87T+KJxkDutIxwX9 9TpqmoYTV+F+dbkq5np1H8MSXgvEuhKE35Q/Lb8qvGjUZQBJI0yGKhWvuLGUAS7U = Received: (qmail 37640 invoked by alias); 20 Jan 2020 18:10:39 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 37631 invoked by uid 89); 20 Jan 2020 18:10:39 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: esa2.mentor.iphmx.com IronPort-SDR: ZMDIIDGVoUG29ytvmCAcX5acpg7cYsEZZ639eyuE5e9ziFBE0XFPE7w0X5Fy25S6UDMTg64dK8 ZtMr0pZyRu5V65/iKgKACxKupoioX/6avDs0AmWLi7+XJFJiKVCjb/kTN9pTkSUU8Z3SmGqZvZ N7ttAe5H9Ikx7Q2cJOAb8WJ4YOVNx2dWkGXK/8j8gfZfI1ewO1xCzDJX7PUbzcj6Ias5OyCeEb 0n4gbiF2D2K4vYsPcS/WLU8H/wCyYN+t9pOZlVKWef/roDlUmcVUqhq3KAsIl73XTwrGwBgk95 fuw= IronPort-SDR: SLF8YBJ6lOdr32wxwJfxzK4mWzQjJm0ChBpshNrVQ393NuyuS8HnLBP7yMeZ65ujLmJ2LiQJKL VtNUTB8JHniA== Date: Mon, 20 Jan 2020 18:10:22 +0000 From: Joseph Myers To: =?KOI8-R?B?8tXNxc4g8MXU0s/X?= CC: "libc-alpha@sourceware.org" Subject: Re: warning: internationalized messages should not contain the '\v' escape sequence In-Reply-To: Message-ID: References: <928503646.1039073.1579042453618@poczta.nazwa.pl> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-1024810385-1579543822=:17298" ---1152306461-1024810385-1579543822=:17298 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT On Sat, 18 Jan 2020, Румен Петров wrote: > Let me quite gettext manual (see url above): > ... > Another example is the ‘argp’ convention to use a single ‘\v’ (vertical tab) > control character to delimit two sections inside a string. This is flawed. I don't see any real difference from e.g. printf format strings. In both cases, there are conventions the string is following that the translated string has to follow as well. What this suggests to me is that there should be a way to mark up a string as using the \v convention for gettext to verify that the translation follows the same convention, just as it can verify that printf formats are consistent between original and translated strings. -- Joseph S. Myers joseph@codesourcery.com ---1152306461-1024810385-1579543822=:17298--