[EURO-Discuss] [At-Large] UA Days

Mon Apr 8 19:01:50 UTC 2024

Hi Olivier,

That's an interesting tool, especially for debugging,  but I'm not sure
what role it plays in UA.

With the same effort that one could use to turn their native text into
punycode with that tool, one could use Google Translate (which has a very
similar interface) and do more.

- Evan

On Mon, Apr 8, 2024 at 6:03 AM Olivier MJ Crépin-Leblond <ocl at gih.com>
wrote:

> Dear Evan,
>
> How about something like this? (which was pointed out to me)
> https://www.punycoder.com/
>
> Kindest regards,
>
> Olivier
>
> On 04/04/2024 05:45, Bill Jouris via At-Large wrote:
>
> Hi Evan,
>
> Consider that some of the apps in play are open source. ICANN could simply
> contribute code to Mozilla, Thunderbird, Wordpress, Signal and other
> projects to make their IDN support seamless. If that support is an
> in-demand feature it will make those applications more desirable in a
> competitive environment.
>
> And I've been arguing, without apparent success, for ICANN to do exactly
> that.
>
> Bill
>
> Sent from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>
> On Wed, Apr 3, 2024 at 11:27 AM, Evan Leibovitch
> <evanleibovitch at gmail.com> <evanleibovitch at gmail.com> wrote:
> Hi Bill,
>
> On Wed, Apr 3, 2024 at 12:18 PM Bill Jouris <b_jouris at yahoo.com> wrote:
>
>
> It seems to me that the function of UA day is inherently NOT directed at
> end users.  It is directed at getting vendors, those who provide software
> interfaces for end users, to make provision for IDNs.
>
>
> Is it really directed at apps developers?
>
> Consider that some of the apps in play are open source. ICANN could simply
> contribute code to Mozilla, Thunderbird, Wordpress, Signal and other
> projects to make their IDN support seamless. If that support is an
> in-demand feature it will make those applications more desirable in a
> competitive environment.
>
>
> End users are, of course, wildly unlikely to be writing their own
> browsers, email systems, etc., so they don't really need to be involved.
>
>
> People aren't writing browsers, email systems, etc. to satisfy the needs
> of ICANN, they're trying to meet the needs of end-users. So if end users
> don't care about IDNs, neither will apps developers, since they have other
> priorities such as speed, security, and *end-user* focused features such
> as VPNs, form auto-completion, spell-checkers, incognito modes and so on.
>
>   (Except to the extend that it would be useful to show some user demand
> when trying to convince vendors to become IDN compatible.)
>
>
> End-user demand for IDNs isn't "useful", it's a mandatory prerequisite.
> Without such bottom-up demand, app developers have no incentive to divert
> resources. In the service of i18n developers place far more emphasis on
> Unicode support, multilingual UI and multilingual integrated search
> engines. If these features satisfy end-user needs then there is no reason
> for them to spend extra effort on IDNs. Developers may well see IDNs as
> just a way for ICANN and its contractors to peddle more domains, and
> without end-user interest they have no incentive to facilitate that.
>
> One must again remind that ICANN is not a treaty-backed organization. It
> has no means to impose, let alone enforce, its decisions on the world. Its
> solutions must be superior and *desired*. Thus, so long as end-user
> demand is not seen as a *necessary* component in advancing IDNs, they
> will remain a non-priority to developers and an avoidable risk to would-be
> IDN registrants.
>
> (Aside: I truly find it amazing that this argument even needs to be made
> within the community tasked with advancing end-user interests within ICANN.)
>
> Making end users aware of the option to use non-ASCII characters for these
> is, to my mind, an entirely separate discussion.
>
>
> If so, that "separate discussion" is the only one worth having within *ICANN
> At-Large*. Other constituencies (civil society, governments, the
> technical community, etc) all have their own places to define and assert
> their own needs.
>
>
> Both whether it is a worthwhile effort and how to go about it if so.  It
> is also something that would really need to be deferred until something
> like Universal Acceptance is available on at least the most widespread
> browsers and email systems.
>
>
> Chicken and egg.
> If end-users don't care about IDNs, browsers and apps won't support them.
> If browsers and apps don't support IDNs, end-users won't care about them.
>
> BTW, the objective is not for browsers to implement "UA".
> Support for IDNs is the solution being pitched, UA is just the name of the
> marketing campaign.
>
>
>   Pitching to end users, when the software they use does not yet support
> IDNs, would be counterproductive.
>
>
> And THAT is why, 20 years from now, ICANN will still be wondering why IDNs
> never caught on.
>
> - Evan
>
>
>
> _______________________________________________
> At-Large mailing listAt-Large at atlarge-lists.icann.orghttps://atlarge-lists.icann.org/mailman/listinfo/at-large
>
> At-Large Official Site: http://atlarge.icann.org
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
>
>
>

-- 
Evan Leibovitch, Toronto Canada
@evanleibovitch / @el56
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://atlarge-lists.icann.org/pipermail/euro-discuss/attachments/20240408/a0386608/attachment-0001.html>