Talk:Find URI in text: Difference between revisions

::::: sorry, i was intentionally opaque. it was <code>&amp;auml;</code> because i was to lazy to copy-paste a real <code>ä</code> until i fixed it. my point though was that the encoding in the text is not relevant to what i am talking about, but the way it is displayed in the address bar. anyways, the whole argument is moot because RFC 3987 covers exactly what i mean and i have updated the task accordingly (thanks again for that pointer).--[[User:EMBee|eMBee]] 16:05, 8 January 2012 (UTC)

:::::: Thanks. I was going to start a discussion on task description but I think you covered it. Even though it's possible to have a good gut feel about what happens, some of these things get picky when you wade into the details. Also this is the price one pays for dabbling in draft tasks :). I may tweak the task description some for elaboration as many may not know what an IRI is. --[[User:Dgamey|Dgamey]] 17:52, 8 January 2012 (UTC)

:it is not necessary to copy the example input exactly. if you can think of other examples that are worth testing, please include them too.

:as for the expected output, this is a question of the balance beween following the rfc and handling user expectations. for example, a <code> . </code> or <code> , </code> at the end of a URI is most likely not part of the URI according to user expectation, but it is a legal character in the RFC. which rule is better? i don't know. until someone can show a live URI that has <code> . </code> or <code> , </code> at the end i am inclined to remove them. in contrast the <code>()</code> case is somewhat easier to decide. if there is a <code>(</code> before the URI, then clearly the <code>)</code> at the end is also not part of the URI, but there are edge-cases too.--[[User:EMBee|eMBee]] 06:58, 8 January 2012 (UTC)