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

Tue Jan 2 09:20:07 UTC 2018

On 1/2/2018 1:07 AM, Asmus Freytag wrote:
> 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./
>

And I fully agree with Andrew Sullivan's remarks. Nothing irks me as 
much as having software that assumes B) is alsways an emoticon, so 
formal legalese texts that have clauses numbered wit (B) all turn into 
nonsense. Runaway linkification promises to be similarly painful 
whenever you are dealing with texts where x.y.y isn't an internet 
address....

>
> 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/2d38c5d4/attachment.html>