all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: wolf <wolf@wolfsden.cz>
To: Julien Lepiller <julien@lepiller.eu>
Cc: guix-devel@gnu.org, Msavoritias <email@msavoritias.me>,
	"Nguyễn Gia Phong" <cnx@loang.net>
Subject: Re: Relaxing the restrictions for store item names
Date: Sun, 27 Aug 2023 17:27:15 +0200	[thread overview]
Message-ID: <ZOtrU86nqmVEDKjd@ws> (raw)
In-Reply-To: <D4AFCB4A-6D41-4224-8E4B-E96AAD8E621A@lepiller.eu>

[-- Attachment #1: Type: text/plain, Size: 5254 bytes --]

On 2023-08-24 12:21:24 +0200, Julien Lepiller wrote:
> Le 24 août 2023 10:41:23 GMT+02:00, Msavoritias <email@msavoritias.me> a écrit :
> >
> >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". But there is very
> >little reasons why we shouldn't strive to be more inclusive of all
> >cultures.
> >Especially since nowadays where we have tools like Unicode that make our
> >lives easier compared to US or nothing of 30-40 years ago.
> >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.
> >
> >MSavoritias
> >
> >MSavoritias <email@msavoritias.me> writes:
> >
> >> Nguyễn Gia Phong <cnx@loang.net> writes:
> >>
> >>> [[PGP Signed Part:Undecided]]
> >>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
> >>>> Nguyễn Gia Phong <cnx@loang.net> 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. Either 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
> >
> >
> 
> There are two things discussed here:
> 
> 1. A restriction in the daemon prevents using unicode in store item names.
> 
> I think this is an issue worth fixing, as it would allow users to define their own store items more easily. For instance, I might want to make a file with non-ascii name a file-like item, eg.
> 
> (local-file "fond d'écran.jpg")

Out of curiosity, do you have an idea how would the list of allowed characters
look like?  Anything except / and \0?  Or something more restrictive?

> 
> 2. Naming policy for packages in the Guix channel
> 
> I don't think we should distribute packages that have non-ascii characters in their names. Of course I don't know all keyboards that exist out there, but I don't think you can find a programmer that can't type an ascii character, or a guix user that can't at least type "guix" in their terminal.
> 
> For discoverability, we could add the real non-ascii name in the package description.
> 

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2023-09-01  9:24 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-22  6:49 Relaxing the restrictions for store item names Eidvilas Markevičius
2023-08-23 19:04 ` jbranso
2023-08-24  6:56 ` (
2023-08-24  7:16   ` MSavoritias
2023-08-24  7:31     ` Nguyễn Gia Phong via Development of GNU Guix and the GNU System distribution.
2023-08-24  7:35       ` Fannys
2023-08-24  7:41       ` MSavoritias
2023-08-24  8:10         ` Nguyễn Gia Phong via Development of GNU Guix and the GNU System distribution.
2023-08-24  8:18           ` MSavoritias
2023-08-24  8:41             ` Msavoritias
2023-08-24 10:21               ` Julien Lepiller
2023-08-24 10:36                 ` MSavoritias
2023-08-24 19:38                   ` (
2023-08-27 15:27                 ` wolf [this message]
2023-08-24 10:33 ` Simon Tournier
2023-08-24 16:30 ` Kaelyn
2023-08-24 18:26   ` Eidvilas Markevičius
2023-09-02 20:02 ` Eidvilas Markevičius
  -- strict thread matches above, loose matches on Subject: below --
2023-08-25  8:37 Nathan Dehnel
2023-08-25  9:14 ` Eidvilas Markevičius
2023-08-25 14:01   ` Eidvilas Markevičius
2023-08-25 16:32     ` Kaelyn
2023-08-25 17:44       ` Eidvilas Markevičius
2023-08-25 18:14       ` Saku Laesvuori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZOtrU86nqmVEDKjd@ws \
    --to=wolf@wolfsden.cz \
    --cc=cnx@loang.net \
    --cc=email@msavoritias.me \
    --cc=guix-devel@gnu.org \
    --cc=julien@lepiller.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.