From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id oBnkNAEV52RJrQAASxT56A (envelope-from ) for ; Thu, 24 Aug 2023 10:29:53 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id sJnqNAEV52R61gAA9RJhRA (envelope-from ) for ; Thu, 24 Aug 2023 10:29:53 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 907DA57BC3 for ; Thu, 24 Aug 2023 10:29:53 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=msavoritias.me header.s=20210930 header.b="JYeu8U/G"; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=msavoritias.me (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1692865793; a=rsa-sha256; cv=none; b=CFCMw7c/E6GQSNo8D1TkXwsuSOK13m2bC2ZZw7cIP2NCdVR9CcorIR71QvUKM5pVzko33K Ljq4XLf//XWChlDtfVZxGFHd+xKhq+0jd3m0YCBV72PvFjUd+rlVhrX8gLi2MqKfyv3LHr tPWV5nEII3aLv53WOgU4yBdfJDSCyXtCQJSc+/rxSXtWNunam6Lr3QHJRRNSk1WdHksRTB lyN6eYHaS7l6uDkTqr76NZJFqshYABLgwjRnTmRDLNgGVZL3mp+14ovHGgZa+xr+Xi6B4Q rivOU5cxRKHij9JgzdSws2GFi69Y6rIFcxvzdcRtYEjBFy2U9qqj3a5URlAg3w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=msavoritias.me header.s=20210930 header.b="JYeu8U/G"; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=msavoritias.me (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1692865793; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=DnB1/66SCiQsC2VlfdiqwQFzYylRI1NOvHu9L6wC/eg=; b=EVp/M7Lhk4ALniJzi0y5zMSzbDvwow0njLV/GMw8jtuCONsgiNJjB0B4J+/inNic18w1e/ 9Ty1ZnQ+AOY/6mC4p6Qrmp6cNht+nbtR0UHgFjGg6olzEE0FXIrR2k9mIYCzYsQh/oqGSN jAJkXRu0dP6B6aKffqNE6HnoKdKjFzHMYCsuPeY1rbSFi9mxkIYJLUD/HqqFMvev3yDAus uSooPAcEsAzAqoJtj97YbG2aRMfhW4pcYpjYQsW56VdbxV1HyQySNHcotMnn512r3UJrwg A8sAY0sZlUvlQ5qEOXLTyBY7PvfG3Q28RSIAO9f2yt11BMEfshciZWGU+6aerw== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZ5iT-00033J-TQ; Thu, 24 Aug 2023 04:29:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qZ5iQ-00032m-4i for guix-devel@gnu.org; Thu, 24 Aug 2023 04:29:19 -0400 Received: from mail.webarch.email ([81.95.52.48]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qZ5iN-0006Ey-Fy for guix-devel@gnu.org; Thu, 24 Aug 2023 04:29:17 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 0F8861A8D0B8; Thu, 24 Aug 2023 09:29:10 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msavoritias.me; s=20210930; t=1692865752; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=DnB1/66SCiQsC2VlfdiqwQFzYylRI1NOvHu9L6wC/eg=; b=JYeu8U/GhwlVq0L0jJIUAa2C/dhpQqaXssR5FXvHHSP1s/C2NVLL/wx4Aq3X1Zb4rRpB3M D9JIJ2WfEDjr0JOxUGlNkOGyBlZ/JnaGleQ75pRXIzWft+0q3VY+UtunRt/ihmgEzHxdCl TJ8WDABUhfedhdMEJYL2qDHWjPhrW81na2X0QDP7VHPqleJdo11EFiCNEYiEe1BWPUNTYz yqKC1SEryLIMM+uTpqAc9GTWrG7Iyv92VivlOOl9xw8phRmfclMmoTrEgkwUUD7l93wesh haApSzckyaAxOuWPr7djE4TrtsrGrj9sQVhAdWQU/WgdhWw4b1aUmpxJTBGZ7Q== References: <87il95gc27.fsf@disroot.org> <875y54zz2t.fsf@fannys.me> <87sf88yjhu.fsf@fannys.me> User-agent: mu4e 1.10.5; emacs 28.2 From: MSavoritias To: =?utf-8?Q?Nguy=E1=BB=85n?= Gia Phong Cc: guix-devel@gnu.org Subject: Re: Relaxing the restrictions for store item names Date: Thu, 24 Aug 2023 11:18:26 +0300 In-reply-to: Message-ID: <87o7iwyhbh.fsf@fannys.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Last-TLS-Session-Version: TLSv1.3 Received-SPF: pass client-ip=81.95.52.48; envelope-from=email@msavoritias.me; helo=mail.webarch.email X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx0.migadu.com X-Spam-Score: -6.11 X-Migadu-Queue-Id: 907DA57BC3 X-Migadu-Spam-Score: -6.11 X-TUID: GV1OXgcn1AeV Nguy=E1=BB=85n Gia Phong writes: > [[PGP Signed Part:Undecided]] > On 2023-08-24 at 10:41+03:00, MSavoritias wrote: >> Nguy=E1=BB=85n Gia Phong writes: >> > I think the distinction must be made here between Guix and GuixSD. >> > >> > The packaging software should support full localization, >> > but the distro should target the least common denominator. >> >> Depends what do we mean the "distro" here. >> If I can pick arabic or chinese in the installation as a display >> language and also I am able to use an arabic/chinese keyboard sounds >> good to me. > > I meant GuixSD. I agree a distribution based on Guix Systems > shouldn't meet any obstacle declaring packages with non-ASCII names. > That you can type arabic and chinese and I can type hangul > and most latin characters doesn't mean names having all of the above > will be accessible to either of us or a third person. > > On 2023-08-24 at 10:41+03:00, MSavoritias wrote: >> Regarding the initial question it was about package names to my >> understanding. Specifically package names in the store to use unicode >> characters. Which makes perfect sense there because some packages dont >> use ascii names. > > It does, but as said before, whether this is desireable depends > on the target audience. The purpose of API is to be used, > i.e. it would be useless if even just one user can't type it. > Well we already have that don't we? What I mean is that ASCII names cant be typed by all keyboards layouts easily. So what you are saying already happens. Thats why I always have an ASCII layout available as a secondary, next to my non ASCII. I bet every person that uses packages with names other than english can add a seperate layout. > On 2023-08-24 at 10:41+03:00, MSavoritias wrote: >> Regarding the broken install example, most (all?) base >> packages use ASCII due to unix historical baggage. >> So you shouldn't need to type anything non ASCII >> to fix an install with only basic packages. > > Due to historical baggage, most (all?) keyboard layouts can fall > back to ASCII alphanumerics. A broken install was given > as the worst case; there's no reason any other packages > should be less accessible based on the users' culture. > But they are already aren't they? Because if I want to add a package with the Greek alphabet or the Japanese one I have to transliterate it into ASCII which is always going to be worse and people won't be able to find the package. Because they won't know we changed the name. Plus they will have to change the layout. Same as an ASCII user would have to do. > I suggest, in an international context such as GuixSD, > for every package to have a ASCII name. It'd of course > be better if a correctly written name is also available. > So you propose two names? Sure if that can be done I don't see why not. Eit= her way not having unicode names is a bug. Also to note: Most of the world speaks Unicode. So its more for compatibility purposes i guess (?) rather than to be "international". MSavoritias