From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 oAMBFZ4v52QfAAAASxT56A (envelope-from ) for ; Thu, 24 Aug 2023 12:23:26 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 0AurFJ4v52TqLgEAauVa8A (envelope-from ) for ; Thu, 24 Aug 2023 12:23:26 +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 10B4167C98 for ; Thu, 24 Aug 2023 12:23:26 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=lepiller.eu header.s=dkim header.b=BHmjBszA; 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=pass (policy=none) header.from=lepiller.eu ARC-Seal: i=1; s=key1; d=yhetil.org; t=1692872606; a=rsa-sha256; cv=none; b=hiTBHJFR+BW1jkA0JDz+L5fvDZ6QF/HLU/DEt3EcMjK5crmR2Uyqxdcqh8r7+KPtqrr4vG 7YDswnlC/zIv2NqcLG/nSyUQ0mw9KjP0OrExtIJwIv8I1MtfgZkxxxWyRxfKaX2XAGJg+B 5M0pare3p+H5c7htwSt3jB7eC22YJ6SOzq/coTmYWLho+4eI3j3coaKlb651WzRXaaME7t V6QQOufjh65PTehuepmq6faCPJzKuPZ9m+hev1i+ue2Ei1KEpegLabRyhGhSeOST2pr6D0 /qSuyQJAmQIXymagJ7Eu9/Xudxn9H5wq0H7Q0kmV+3NiBprx01+mx/27udpG9A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=lepiller.eu header.s=dkim header.b=BHmjBszA; 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=pass (policy=none) header.from=lepiller.eu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1692872606; 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=WRrNqz1g7OcgbeM57JyWA86bkbRP/RrFM/szunQxCJo=; b=Eov4ULqd311xv6gSPUYQi/i67vG5V/89lNxLYFau7Rynw33XAMa3ZmGpMb/jCaLh8fmgUZ G6RB9NftHUE+LYUtmSQN9/2DAhbGEk/2IVR0l2ozAUAVderIL16MBwsBHEVzr62ucqBQXJ z6Y9Nz8lP5Sc9SzG5ucCJWEPDB8vLTJ5F/xyj/a8NtZkX2cYCI7vCAxDGzEhkEJSXRCmp5 3E9qJe8XM63CjOD0m8RJltETvsy3Q6kUVSPWTZV0J+YdutaJh/q4TNdt3zJEVPfRBUDR5P TDjarGiWYRETZIe7d9xecfCrw90itGAH7Cc12FcU+jX9PyGKOLgtW+8avQhGNw== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZ7UK-0004Fr-Js; Thu, 24 Aug 2023 06:22:52 -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 1qZ7UI-0004Fj-O7 for guix-devel@gnu.org; Thu, 24 Aug 2023 06:22:50 -0400 Received: from lepiller.eu ([2a00:5884:8208::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qZ7UG-0006iH-0j for guix-devel@gnu.org; Thu, 24 Aug 2023 06:22:50 -0400 Received: from lepiller.eu (localhost [127.0.0.1]) by lepiller.eu (OpenSMTPD) with ESMTP id 8b9fa490; Thu, 24 Aug 2023 10:21:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=lepiller.eu; h=date:from :to:cc:subject:in-reply-to:references:message-id:mime-version :content-type:content-transfer-encoding; s=dkim; bh=TczBJAxK4rDc k+lNbUkddOow5LCWxyeORFSPLHIoIuw=; b=BHmjBszA2vA7I0aLBvZjcRw8ovkP ULzyI4WlKYi9w7FfAe954maWqW7wEVgPIp7rhmoU0VKoigfZswHOtTN3Sjg8xSVz 5wLZQQkEao4NTJtxXiKPX7EKy3GHtD4D9plIOSSUrFz36Kd6XU52z6Bt3XE0eCy0 YhxlJtlyh840r7QTVm/oJTuviiYv3GXxzmt/RrGNcD41JkP/osSYvpxh/NyCPl51 suBghfbLAOCAfiGlGhyYKhLWJ7gLHvgvvsfhomN6EZ5HDiXGfMHeuwuTGbuv/iIo qO4JdlNen2wmTQegI5L5ZZrfMb9KLU6ettoJJvLfd/dWWBLnY7lV4Rlkdg== Received: by lepiller.eu (OpenSMTPD) with ESMTPSA id 289d9f54 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 24 Aug 2023 10:21:33 +0000 (UTC) Date: Thu, 24 Aug 2023 12:21:24 +0200 From: Julien Lepiller To: guix-devel@gnu.org, Msavoritias , MSavoritias CC: =?UTF-8?Q?Nguy=E1=BB=85n_Gia_Phong?= Subject: Re: Relaxing the restrictions for store item names User-Agent: K-9 Mail for Android In-Reply-To: <87jztkyglb.fsf@fannys.me> References: <87il95gc27.fsf@disroot.org> <875y54zz2t.fsf@fannys.me> <87sf88yjhu.fsf@fannys.me> <87o7iwyhbh.fsf@fannys.me> <87jztkyglb.fsf@fannys.me> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:5884:8208::1; envelope-from=julien@lepiller.eu; helo=lepiller.eu X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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: -7.41 X-Migadu-Queue-Id: 10B4167C98 X-Migadu-Spam-Score: -7.41 X-TUID: E6cpq0bztbyv Le 24 ao=C3=BBt 2023 10:41:23 GMT+02:00, Msavoritias a =C3=A9crit=C2=A0: > >What I am saying here is that: >Its easy to see from our very US centric tech culture why everybody >should just use ASCII because "This is how it is"=2E But there is very >little reasons why we shouldn't strive to be more inclusive of all >cultures=2E >Especially since nowadays where we have tools like Unicode that make our >lives easier compared to US or nothing of 30-40 years ago=2E >Just imagine how many good programmers we are missing because they don't >want/can't learn English or don't have an ASCII keyboard=2E > >MSavoritias > >MSavoritias writes: > >> 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= =2E >>>> > >>>> > The packaging software should support full localization, >>>> > but the distro should target the least common denominator=2E >>>> >>>> Depends what do we mean the "distro" here=2E >>>> 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=2E >>> >>> I meant GuixSD=2E I agree a distribution based on Guix Systems >>> shouldn't meet any obstacle declaring packages with non-ASCII names=2E >>> 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=2E >>> >>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote: >>>> Regarding the initial question it was about package names to my >>>> understanding=2E Specifically package names in the store to use unico= de >>>> characters=2E Which makes perfect sense there because some packages d= ont >>>> use ascii names=2E >>> >>> It does, but as said before, whether this is desireable depends >>> on the target audience=2E The purpose of API is to be used, >>> i=2Ee=2E it would be useless if even just one user can't type it=2E >>> >> Well we already have that don't we? What I mean is that ASCII names can= t >> be typed by all keyboards layouts easily=2E So what you are saying alre= ady >> happens=2E Thats why I always have an ASCII layout available as a >> secondary, next to my non ASCII=2E I bet every person that uses package= s >> with names other than english can add a seperate layout=2E >> >>> 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=2E >>>> So you shouldn't need to type anything non ASCII >>>> to fix an install with only basic packages=2E >>> >>> Due to historical baggage, most (all?) keyboard layouts can fall >>> back to ASCII alphanumerics=2E 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=2E >>> >> >> 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 t= o >> find the package=2E Because they won't know we changed the name=2E Plus= they >> will have to change the layout=2E Same as an ASCII user would have to d= o=2E >> >>> I suggest, in an international context such as GuixSD, >>> for every package to have a ASCII name=2E It'd of course >>> be better if a correctly written name is also available=2E >>> >> >> So you propose two names? Sure if that can be done I don't see why not= =2E Either way not >> having unicode names is a bug=2E Also to note: Most of the world speaks >> Unicode=2E So its more for compatibility purposes i guess (?) rather th= an >> to be "international"=2E >> >> MSavoritias > > There are two things discussed here: 1=2E A restriction in the daemon prevents using unicode in store item name= s=2E I think this is an issue worth fixing, as it would allow users to define t= heir own store items more easily=2E For instance, I might want to make a fi= le with non-ascii name a file-like item, eg=2E (local-file "fond d'=C3=A9cran=2Ejpg") 2=2E Naming policy for packages in the Guix channel I don't think we should distribute packages that have non-ascii characters= in their names=2E Of course I don't know all keyboards that exist out ther= e, but I don't think you can find a programmer that can't type an ascii cha= racter, or a guix user that can't at least type "guix" in their terminal=2E For discoverability, we could add the real non-ascii name in the package d= escription=2E