On Fri, Dec 2, 2016 at 10:31 AM Nate Finch <nate.fi...@canonical.com> wrote:
> One thing we *could* do to support non-english names that would not > entirely open the door to emoji etc is to simply constrain the names to > unicode letters and numbers. Thus you could name something ζΈζεΊ« but > not π©π©π©π©. > I bothered Rick about this a while ago (half jokingly) since I own http:// π©β.ws <http://xn--l3h.ws> (poo cloud!) and was going to make a charm accompanying that name. Localized unicode characters - emoji or otherwise - are still a difficult UX compared to alphanumerics. It takes me 10 mins to find the emojis to type the damn domain in if I'm not on a phone. The only path for unicode names I could see happening, and it's a stretch, is if the application name can be set to a larger range of characters. Where you may want to name horizon deployed in your environment to something localized (or emoji) but the charm name should be flat and simple. On Fri, Dec 2, 2016 at 9:29 AM Mark Shuttleworth <m...@ubuntu.com> wrote: > > On 02/12/16 09:23, Adam Collard wrote: > > True, but we could do normalisation in the charm store to prevent > malicious names. I think it's an important aspect of software in the modern > world that it can support the wide array of languages that we humans use. > > > This just transfers the definition of 'OK' to a different codebase. > > It's much better to have a simple rule that can be well documented, > enforced the same way in store and client and snapd, and typed on any > laptop without having to refer to the internet for assistance. > > > Mark > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
