Re: [CODE4LIB] Best way to handle non-US keyboard chars in URLs?

[Stuart A. Yeates]

Use en-wiki style disambiguation?

Cheers
Stuart

On Saturday, 20 February 2016, Andy Kohler  wrote:

> >
> > Interested to hear if there's a 4th, best option.
> >
>
> I don't know about the broader issue - looking forward to that discussion!
> But in this example at least, it seems wrong to be using names as the
> identifier at all, because names aren't unique.  What happens when you need
> a URI for another Bob (or another Itajaí Cêrebro Raízes)?  So a 4th option
> here might be, use better identifiers in the URI and side-step the whole
> messy issue.
>
> /me sits in ivory tower eagerly waiting for the real world to join me :)
>
> --Andy
>


-- 
--
...let us be heard from red core to black sky

Re: [CODE4LIB] Best way to handle non-US keyboard chars in URLs?

[Andrew Cunningham]

i,
On Monday, 22 February 2016, Chris Moschini  wrote:
> On Feb 20, 2016 9:33 PM, "Stuart A. Yeates"  wrote:
>>
>> 1) With Unicode 8, sign writing and ASL,  the American / international
>> dichotomy is largely specious. Before that there were American indigenous
>> languages (Cheyenne etc.), but in my experience Americans don't usually
>> think of them them as American.
>
> It's not about the label, so don't get too hung up on that. It's about
> what's easy to type on a typical US keyboard.
>

If you are accessing a non-English resource, then having characters outside
the basic latin block would seem to be perfectly acceptable to me.

There are two types of users involved .. those that xan read the target
language and those that can't.

Those you can should be able to work with keyboards other than a US English
layout. On most devices this is fairly trivial. Not to mention the user may
jot actuually have the US English keyboard layout as their default input
system.

On a multilingual site I prefer the access points to be in the language of
the resource.

Obviously there are cases where people who can not read the language need
to access a resource. In those cases I would look at apis that expose the
resource in a different way. Maybe through a transliteration mapping.
Rather than having a second URL.

Ultimately it comes fown to who the users are and why they are accessing
the resource.

It seems to me your primary concern is for users who can not read the
resource in any event

Andrew

-- 
Andrew Cunningham
lang.supp...@gmail.com

Re: [CODE4LIB] Best way to handle non-US keyboard chars in URLs?

[Kyle Banerjee]

>
> > 3) Who type un-shortened URLs any more?
>
> I'm looking for responses that solve this rather than dismiss Intuitive
> URLs.
>

The question is what the use case you're trying to solve looks like. Is the
goal typability because it's hand transcribed from a business card, knowing
what the link connects to without following it, identification, search
engine optimization, something else, a combination of these things, etc?

Hand typed URLs that are not copied and pasted need to be short and not
look like gibberish. Transliteration schemes not known to people typing
them confuse rather than help. Whatever route you take, you'll be
optimizing one or more objectives at the expense of something else.

kyle

Re: [CODE4LIB] Best way to handle non-US keyboard chars in URLs?

[Chris Moschini]

On Feb 20, 2016 9:33 PM, "Stuart A. Yeates"  wrote:
>
> 1) With Unicode 8, sign writing and ASL,  the American / international
> dichotomy is largely specious. Before that there were American indigenous
> languages (Cheyenne etc.), but in my experience Americans don't usually
> think of them them as American.

It's not about the label, so don't get too hung up on that. It's about
what's easy to type on a typical US keyboard.

> 2) Google and friends are more than capable of handling redirects, even
> when done badly.

Google punishes redirects actually. #38 here:

https://blog.kissmetrics.com/penalized-by-google/

But you can find plenty more discussion of the redirect penalty. Not
redirecting would mean duplicate content which is also punished - see #3.

> 3) Who type un-shortened URLs any more?

I'm looking for responses that solve this rather than dismiss Intuitive
URLs.

For example a bunch of random chars or an ID for each url guarantees
uniqueness, but it's much less useful to the user. It looks like nonsense
and you won't be recalling it later. You're not going to be able to
describe the url to someone else, and if you IM it to someone or they see
it on another website the link gives them little confidence that click will
get them what's promised.

https://www.deepcrawl.com/knowledge/best-practice/guide-to-url-design/

[CODE4LIB] Call for Product Feedback: Nete

[Timothy Tavarez]

Heya folks,

I'm Timothy Tavarez - founder of a small startup in Colorado Springs, CO
that is developing an ILS called Nete for public libraries. I'm hoping to
get some early feedback on all sorts of things, ranging from how we'll do
business all the way the product itself.

Nete is in alpha, but it has some pretty cool features that folks will
likely be interested in.

If anyone is interested, please let me know!

Timothy Tavarez
Founder
Nete

t.
719-424-9820
e.
timothy.tava...@nete.io
w.
http://nete.io
a.
415 N Tejon St, Colorado Springs, CO

Re: [CODE4LIB] Call for Product Feedback: Nete

[Timothy Tavarez]

Whoops. A word.

*ranging from how we'll do
business all the way **to the product itself.