[UA-discuss] linkification - was Re: Universal Acceptance now on Wikipedia...https://en.wikipedia.org/wiki/Universal_Acceptance

Asmus Freytag asmusf at ix.netcom.com
Tue Jan 2 09:07:20 UTC 2018


I'm amazed at the level of detail that you are proposing here. I'm sure 
it would allow and advanced user to get precisely the desired behavior - 
until the next update that erases all the preferences...

In other words, I can see this level of control as useful for a 
"production" environment, like a word processing app, but most casual 
users would neither know that the behavior might be controlled by 
preferences nor have a systematic idea of how to translate any "this 
isn't working the way I want to" into settings.

Skeptically,
A./


On 1/1/2018 10:27 AM, Andre Schappo wrote:
> I believe I can now address Andrew's concerns about schemes other than 
> http and https
>
> In the user linkification preferences, the user should be able to 
> specify the presentation form.
>
> So, for http://한국인터넷정보센터.한국 
> <http://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e> I would 
> specify that I wanted it presented as 한국인터넷정보센터.한국 
> <http://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e>
>
> But for a different scheme, say smb://label1.label.example 
> <smb://label1.label.example> I could choose in my linkification 
> preferences I do not want it to be linkified. I think that for other 
> schemes, if I wanted it to be linkified, I would probably retain the 
> scheme prefix ie smb://label1.label2.example in order to make it clear 
> this is not a web address.
>
> André Schappo
>
>> On 1 Jan 2018, at 15:36, Andre Schappo <A.Schappo at lboro.ac.uk 
>> <mailto:A.Schappo at lboro.ac.uk>> wrote:
>>
>> Have given more thought on user controlled linkification and there 
>> are other user options that may be useful
>>
>> Ⓐ Let the user select which TLDs will result in linkification of 
>> domain names. A user could, for example, choose not to allow 
>> linkification of domains names with the TLD .porn. Or a user could 
>> allow linkification of all domain names which have an India domain 
>> name, of which there are an impressive number.
>> Ⓑ Let a user specify a fictious TLD which does not result in 
>> linkification of a domain name. I would find this useful because I 
>> often write fictious domain names which I do not want linkified. So I 
>> could setup a fictious TLD, say .example which would not get 
>> linkified. Then I could put such domain names in my teaching material 
>> without auto linkification rather than having, for example, 
>> https://label1.label2.example <https://label1.label2.example/> which 
>> auto linkifies in Apple Mail and many other Apps.
>> Ⓒ Let a user disallow linkification of mixed script domain names, as 
>> in each label having different scripts eg hindi.arabic.chinese
>>
>> André Schappo
>>
>>> On 31 Dec 2017, at 18:47, Andre Schappo <A.Schappo at lboro.ac.uk 
>>> <mailto:A.Schappo at lboro.ac.uk>> wrote:
>>>
>>> Good point.
>>>
>>> Perhaps rather than more sophisticated linkification we need more 
>>> sophisticated system wide user link settings/preferences ie settings 
>>> under the control of the user.
>>>
>>> My first stab at such user link settings are:-
>>>
>>> ----------------------
>>> Check to enable your preferred link settings
>>>
>>> 1️⃣ automatically linkify everything possible ⬜️
>>>
>>> 2️⃣ automatically linkify (check all those from the following that 
>>> apply)  -
>>> 2️⃣ A. text having the form "http://a.domain.name 
>>> <http://a.domain.name/> ⬜️
>>> 2️⃣ B. text having the form https://a.domain.name 
>>> <https://a.domain.name/>  ⬜️
>>> 2️⃣ C. text having the form www.a.domain.name 
>>> <http://www.a.domain.name/>  ⬜️
>>> 2️⃣ D. text having the form a.domain.name.in.non.ascii.text  ⬜️
>>> 2️⃣ E. text having the form www.a.domain.name.in.non.ascii.text 
>>> <http://www.a.domain.name.in.non.ascii.text/> ⬜️
>>>
>>> ...etc...
>>> ----------------------
>>>
>>> I would have 2️⃣ B checked and 2️⃣ A unchecked because when I have 
>>> time I usually check if a site supports https when I have been given 
>>> the http form.
>>>
>>> I will give it more thought tomorrow but now it is time for New Year 
>>> celebrations.
>>>
>>> So, again, Happy New Year
>>>
>>> André Schappo
>>>
>>>
>>>> On 30 Dec 2017, at 18:53, Andrew Sullivan <ajs at crankycanuck.ca 
>>>> <mailto:ajs at crankycanuck.ca>> wrote:
>>>>
>>>> I sincerely hope that linkification of bare domain names does _not_ 
>>>> take over, because it gets in the way. The Internet is bigger than 
>>>> the web, and we aim for something too poor if we nail ourselves 
>>>> forever and only to https.
>>>>
>>>> A
>>>>
>>>> -- 
>>>> Please excuse my clumbsy thums
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> On December 30, 2017 6:19:11 AM Andre Schappo 
>>>> <A.Schappo at lboro.ac.uk <mailto:A.Schappo at lboro.ac.uk>> wrote:
>>>>
>>>>> Really good to see UA on wikipedia. It feels like UA has made the 
>>>>> mainstream.
>>>>>
>>>>> 2 suggestions:-
>>>>>
>>>>> 1️⃣ In the wikipedia article there are indirect references to 
>>>>> https://uasg.tech <https://uasg.tech/> eg 
>>>>> https://uasg.tech/wp-content/uploads/2017/09/UASG-Report-UASG016.pdf I 
>>>>> think there should be a direct reference to uasg home page in the 
>>>>> wikipedia article ie https://uasg.tech <https://uasg.tech/>
>>>>>
>>>>> 2️⃣ drop the www —  eg in the wikipedia article there is the link 
>>>>> https://www.icann.org/resources/pages/universal-acceptance-2012-02-25-en I 
>>>>> suggest using 
>>>>> https://icann.org/resources/pages/universal-acceptance-2012-02-25-en instead. 
>>>>> My experience is that the majority of people think the initial www 
>>>>> is necessary but in the majority of web addresses the www is not 
>>>>> necessary. My reasoning is that having the www prefix is contrary 
>>>>> to IDNs because one then has mixed scripts in an IDN. Take Korea 
>>>>> NIC. Their IDN is https://한국인터넷정보센터한국 
>>>>> <https://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/> They do 
>>>>> support https://www.한국인터넷정보센터.한국 
>>>>> <https://www.xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/> but 
>>>>> they do not make the www necessary and they do not redirect to the 
>>>>> www form.
>>>>>
>>>>> Now, what I have written is also contradictory because I have used 
>>>>> https:// so that my Apple Mail App will linkify. When I put links 
>>>>> in my webpages I would only display to users 한국인터넷정보센터.한국 
>>>>> My hope for the future is that linkification will become more 
>>>>> sophisticated and be able linkify 한국인터넷정보센터.한국 without the 
>>>>> need for www or https:// thus resulting, in this case, a fully 
>>>>> korean hangeul domain name.
>>>>>
>>>>> So, I suggest the working practice — when possible (which I think 
>>>>> is most of the time), drop both the www and https:// when 
>>>>> presenting the domain name to end users.
>>>>>
>>>>> André Schappo
>>>>>
>>>>>> On 30 Dec 2017, at 08:15, Don Hollander <don.hollander at icann.org 
>>>>>> <mailto:don.hollander at icann.org>> wrote:
>>>>>>
>>>>>> A nice way to end a fairly productive year.
>>>>>>
>>>>>
>>>
>>>
>>
>>
>
> 🌏 🌍 🌎
> André Schappo
> https://schappo.blogspot.co.uk
> https://twitter.com/andreschappo
> https://weibo.com/andreschappo
> https://groups.google.com/forum/#!forum/computer-science-curriculum-internationalization 
> <https://groups.google.com/forum/#%21forum/computer-science-curriculum-internationalization>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20180102/fe7aba6c/attachment.html>


More information about the UA-discuss mailing list