On Friday, November 18, 2016 at 9:59:41 PM UTC+1, Jeremy Ruston wrote:
>
> Hi Mario
>
> Hi,
> Just an idea. 
> If we implement a simple version of fuzzy search, which imo will be highly 
> useful in general, it could use the transliteration extension, if the exact 
> title isn't found. 
> -m
>
>
> Interesting idea. I’d need some persuading that there wouldn’t be 
> unintended consequences. The alternative I’ve wondered about is to support 
> an explicit “slug” field, like Wordpress:
>
> https://en.wikipedia.org/wiki/Semantic_URL#Slug
>
> The slug could be optional, defaulting to the URI encoded title as at 
> present. There would need to be a requirement that the slug only contain 
> the limited set of characters permitted in an URL fragment identifier.
>

So as I read it, there would be some generic rules: 

 1) the slug-field is optional
 2) the slug character set is limited to eg: latin characters, digits, and 
hyphen "-" ... nothing else
 3) if no slug field is present, use the permalink mechanism as it is 
today. 
 4) The whole slug creation process is manual ... so the OT thoughts about 
some helper functions doesn't apply. 

My concern here is point 4). Since an automatic slug creation process is 
language specific, it is plugin territory. eg: Cyrillic needs different 
handling than German.
If we don't provide best practice documentation, we will end up with an 
unpredictable mess. 

As soon as the slug field is implemented, we will get feature requests 
about auto-creation. So imo it's worth to think about it now already. see OT

------------- OT ----------------

Some plugin implementation thoughts 

add 1) 
 1.1 If the slug-filed is empty for eg: "Hello World", what happens if the 
user opens a permalink +#hello-world?
 1.2 how is duplication like: "Hello World" vs "hello world" resolved? it 
creates the same slug: #hello-world
 1.3 How do we resolve transliteration in a human predictable way. .. This 
is language dependent. see OP or for German:  Hände vs hande vs haende

add 2) 
 2.1 The URI-fragment definition allows URLencoded chars. ... We don't want 
this. 
 2.2 So we will limit it to: ALPHA / DIGIT / "-"
 2.3 how do we resolve duplications? see 1.2
       
links: 
 - URI fragment is defined at: RFC3986 
<https://tools.ietf.org/html/rfc3986#section-3.5> see: appendix A 
<https://tools.ietf.org/html/rfc3986#appendix-A> for the chars allowed.

------------- OT end ----------------

have fun!
mario

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/d4aa9d88-3e9a-47ea-b78b-762fd1cc9fad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to