> On 21 Apr 2017, at 15:36, Miroslav Galajda <miroslav.gala...@gmail.com> wrote: > > Hi, > the solution I've described is javascript based and runs on client-side. > From what I know, the component-based solution, which you propose, would > require to have url-friendly conversion component usable in java and not as > javascript code. Am I right?
Yes you’re right but: 1) There’s also a Java API, see https://github.com/slugify/slugify 2) If we also offer a UIX then it can be implemented in a wiki page for example and you can use JS. Thanks -Vincent > On 21 April 2017 at 15:28, Vincent Massol <vinc...@massol.net> wrote: > >> Hi Miroslav, >> >>> On 21 Apr 2017, at 15:05, Miroslav Galajda <miroslav.gala...@gmail.com> >> wrote: >>> >>> Hi, let me enter into this conversion. >>> Some time ago I've asked for help how to solve problem with diacritics >> (or >>> accents) in page names when creating new pages so that the have >>> url-friendly names. You can search for "strip accents from page name used >>> in url" in xwiki users mailing list. I've got no hint or solution from >>> xwiki community till today. >>> >>> I've come with solution that ensures for simple users, creating >>> url-friendly names without requiring them to think about the concept of >> the >>> page name or page title. They simple enter the desired human readably >> page >>> name, and in the code behind of the page creation, I have made some >>> modifications in createinline.vm to hook into page creation process. The >>> modifications are mainly javascript based, where I've attache to submit >>> event of the "form#create", where I replace the entered "title" with the >>> one for url-friendly. And for url-friendly name I've used this javascript >>> based solution on https://pid.github.io/speakingurl/. >>> I've integrated this principle also into page creation process of FAQ and >>> Blog applications, which we are using in our xwiki installation. >>> >>> It would be nice if you could integrate this principle into xwiki so that >>> everyone can have nice url-friendly urls without worring about it. It is >>> also suitable for english speaking users. You don't have to worry about >>> entering spaces or other non-url allowed characters, which make url look >>> ugly. >> >> That looks very nice! >> >> One way forward I could think about: >> * We provide some Create script service to return a URL-friendly string. >> We introduce a component role for this. We refactor createinline.vm to use >> it and to display the URL. >> * You could then contribute your code as an extension that we make >> available on extensions.xwiki.org for users to install >> * We decide later on if we want to bundle it by default >> >> If we don’t agree about displaying the URL by default all the time then an >> option is to introduce a UIX in createinline.vm for that. And this could be >> implemented in your extension too for example or by default in XWiki >> (possibly with an Admin setting). >> >> WDYT? >> >> Thanks >> -Vincent >> >>> >>> Thank you >>> >>> Best regards >>> Miroslav Galajda >>> >>> On 21 April 2017 at 14:02, Vincent Massol <vinc...@massol.net> wrote: >>> >>>> >>>>> On 21 Apr 2017, at 13:52, Marius Dumitru Florea < >>>> mariusdumitru.flo...@xwiki.com> wrote: >>>>> >>>>> On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol <vinc...@massol.net> >>>> wrote: >>>>> >>>>>> Hi Caty, >>>>>> >>>>>>> On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) < >> vali...@gmail.com >>>>> >>>>>> wrote: >>>>>>> >>>>>>> Let's see what variants we have: >>>>>>> >>>>>>> 1. Instead of displaying "Title", display the "Name" instead. >>>>>>> This won't solve anything. There is no difference between Page Name >> and >>>>>>> Page Title for the normal users. Seeing "Name" instead of "Title", >> will >>>>>> not >>>>>>> stop the users to enter spaces if they want, so the URL will still >> have >>>>>>> those spaces. We don't force the Page Names to trim spaces. >>>>>>> >>>>>>> One quick solution here is indeed to use "URL" label instead of >> "Name". >>>>>> For >>>>>>> the reasons Vincent mentioned this might not end up in the product >> for >>>>>> now, >>>>>> >>>>>> What did I mention? :) What’s preventing us from having it in the >>>> product >>>>>> rather soon than later (except workload ofc)? >>>>>> >>>>>>> so you will need to do some custom development (changing some >>>>>> translations) >>>>>>> to have this change. If you want to be "hackish" you can even change >>>> the >>>>>>> translation for "Title" to "URL" instead and hope that your users >> will >>>>>>> enter shorter URLs (since we generate the name from the title). >>>>>>> >>>>>>> Displaying just Name / URL, means users will still have to go and >>>> change >>>>>>> the title manually. >>>>>> >>>>>> This could be better (with URL name) since when you create a page >> you’re >>>>>> offered the ability to change the title after you click Create. >>>>>> >>>>>>> The only way to cut a step in the flow is to >>>>>>> autogenerate the page names (which we currently do). But for your use >>>>>> case >>>>>>> you shoyld write a shorting/trimming algorithm, but this is custom, >>>> since >>>>>>> you mentioned you want just the initials and no spaces, etc. >>>>>>> >>>>>>> 2. Displaying both "Title" and "Name". This will create confusion and >>>>>> need >>>>>>> for explanations. >>>>>> >>>>>> This is not exactly what is suggested either by Vishal nor by me :) >> What >>>>>> we suggested is to let the user enter the URL name and title. >>>>>> >>>>>> Actually and to be more precise what I was suggesting was to continue >> to >>>>>> let the user enter the title but to show the generated URL as it’s >> done >>>> in >>>>>> AWM. And, importantly to allow the user to change the last part of the >>>> URL >>>>>> (it would change the page name). >>>>>> >>>>>>> That's why we display these options just for advanced and >>>>>>> long-time users of XWiki, since they are used to the concepts. >>>>>> >>>>>> >>>>> >>>>>> Yes but URLs don't need an advanced user to understand the concept >> and I >>>>>> agree with Vishal that we’re now causing a very large number of pages >> to >>>>>> have %25 in their URLs by default which is quite bad… Of course >> someone >>>> can >>>>>> spend their time monitoring what users are doing and renaming pages >>>>>> thereafter or educate their users to do that but we’re not helping and >>>>>> we’re making it difficult. >>>>>> >>>>> >>>>> If your web site is not in English then you're forced to use special >>>>> characters like diacritics which makes it hard to avoid URL encoded >>>>> characters (the browser location bar displays the URL nicely but if you >>>>> copy the URL the result is not nice). >>>> >>>> Agreed. So I’d say it’s even more important to allow the user to be able >>>> to easily view and change the resulting URL when they’re not in English. >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> >>>>> >>>>>> >>>>>>> ----- >>>>>>> >>>>>>> IMO what you are describing is advanced user behavior. Normal users >>>> don't >>>>>>> generally care about their URLs and SEO. >>>>>> >>>>>> I don’t fully agree with you. I have the feeling (can’t prove it) >> that a >>>>>> good number of our users care about the generated URLs. >>>>>> >>>>> >>>>>> Also I think that simple users may care about URL without being >> advanced >>>>>> users. Making them advanced users will expose them to a lot more >>>> complexity >>>>>> than they need to know. >>>>>> >>>>>>> But the beauty of XWiki is that >>>>>>> you can customize it locally to perfectly match your needs. >>>>>> >>>>>> That’s not exactly true (and it’s far from being easy, just check >>>>>> createinline.vm): It means overriding large portions of vm code and >>>> having >>>>>> to do manual merges whenever you upgrade. A major PITA. >>>>>> >>>>>>> Vincent mentioned something about AWM. I don't see much difference >> from >>>>>> the >>>>>>> Create Page. We generate the names from title here too. We display >> them >>>>>> in >>>>>>> the breadcrumb, but in a more simple way. Displaying the >>>>>> "localhost"/server >>>>>>> part is not simple user behavior. AWM is more complex. >>>>>>> >>>>>>> ----- >>>>>>> >>>>>>> So I would not change anything on the product side, since I believe >>>> these >>>>>>> should be solved as custom changes for your instance. >>>>>>> We want to encourage users to use page titles (with spaces in them >>>> since >>>>>>> they are more readable and supported), while we are preserving the >> page >>>>>>> name behavior for advances users (but we don't enforce it). >>>>>> >>>>>> I don’t agree with this sentence: We definitely don’t want to >> encourage >>>>>> users to use titles in URLs. >>>>>> >>>>>>> If users made >>>>>>> mistakes they can always change the title or rename the page. >>>>>>> On the product side the only change I would like us to do is using >> the >>>>>> URL >>>>>>> naming, but this was debated in the past and dropped for Vincent's >>>>>> reasons. >>>>>> >>>>>> What reasons, I don’t remember a discussion about using URL name >> instead >>>>>> of page name? >>>>>> >>>>>> So our main disagreement is that I consider that favouring encoded >>>>>> characters in URLs is not a good thing while you think it’s not a >> large >>>>>> enough problem to do something about it. >>>>>> >>>>>> Would it make our UI too complex to use for simple users if we were >>>>>> showing a URL and the ability to change the last part of it? IMO >> what’s >>>>>> complex is when we have Page name and Page Title. But I don’t feel >>>> there’d >>>>>> be confusion between URL and Page title. >>>>>> >>>>>> What do others think? >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Caty >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol <vinc...@massol.net >>> >>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>>> On 20 Apr 2017, at 22:51, Vincent Massol <vinc...@massol.net> >> wrote: >>>>>>>>> >>>>>>>>> Hi Vishal, >>>>>>>>> >>>>>>>>> Ok, I misunderstood you in your first email. I understood the >>>> opposite. >>>>>>>> I thought you were complaining that have 2 notions (page name + page >>>>>> title) >>>>>>>> was confusing but it’s actually the opposite! What you find >> confusing >>>> is >>>>>>>> the fact that it’s not easy for your users to set both the page name >>>> and >>>>>>>> page titles! >>>>>>>>> >>>>>>>>> It’s funny (or not :)) since this is exactly what we had in past >>>>>>>> versions of XWiki and we had several complaints that it was >> confusing >>>> to >>>>>>>> have the 2 notions and this is why he hid the page name only for >>>>>> advanced >>>>>>>> users. >>>>>>>> >>>>>>>> Actually, if I remember well, what we were doing was to ask for the >>>> page >>>>>>>> name and we were setting the title to the same as the page name by >>>>>> default >>>>>>>> and then the user could edit the title before saving the page. >>>>>>>> >>>>>>>> We’ve now done the opposite (user deciding on the title and page >> name >>>>>>>> being derived from it) but leading to the issue you’re raising about >>>> URL >>>>>>>> SEO… >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>> >>>>>>>>> See below. >>>>>>>>> >>>>>>>>>> On 20 Apr 2017, at 14:20, Vishal <thewikinote...@gmail.com> >> wrote: >>>>>>>>>> >>>>>>>>>> Thanks Vincent for your thorough reply.. >>>>>>>>>> You guessed it right. We intend to have clean and short urls for >> SEO >>>>>>>>>> reasons. >>>>>>>>>> Current scheme creates two problems: >>>>>>>>>> >>>>>>>>>> 1) The Page name is fetched automatically from the Title. Often >> the >>>>>>>> titles >>>>>>>>>> have spaces which translate as *percent characters *in url which >>>> makes >>>>>>>> it >>>>>>>>>> somewhat unclean :) >>>>>>>>> >>>>>>>>> Indeed you’re right. By hiding the page name we’re now incitating >> to >>>>>>>> have longer URLs and encoded characters showing up in URLs which is >>>> not >>>>>>>> nice I agree. >>>>>>>>> >>>>>>>>> Maybe one solution is to do something similar to what we do in AWM, >>>>>> i.e. >>>>>>>> generate automatically the URL from the title entered by the user >> and >>>>>> show >>>>>>>> the resulting URL to the user and give the user the opportunity to >>>>>> change >>>>>>>> the URL. >>>>>>>>> >>>>>>>>> See http://extensions.xwiki.org/xwiki/bin/download/Extension/ >>>>>>>> App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png >>>>>>>>> >>>>>>>>>> 2) Secondly, to have the shorter url, we use only the short forms >> of >>>>>>>>>> complete title. >>>>>>>>>> Ex. For title 'Pune University' we use name PU. >>>>>>>>> >>>>>>>>> Hey, you’re from Pune? :) I’ve been there about 15 times! That was >>>> in a >>>>>>>> previous job where my company and KPIT Cummins were partners. >>>>>>>>> >>>>>>>>>> Otherwise in this hierarchy of pages, the url would be much >> longer. >>>>>>>>>> Ex. We have page 'Electronics and Telecommunications' branch under >>>>>> page >>>>>>>>>> 'Pune University'. We should not have such a long url. Instead >> here >>>> we >>>>>>>> need >>>>>>>>>> PU/ENTC or Pune-University/ENTC >>>>>>>>>> >>>>>>>>>> To avoid all this, what we currently do: >>>>>>>>>> 1) On create page dialog, use PU as title.. This will create url >> as >>>>>> PU. >>>>>>>>>> If full name is used here as title, we need to use - instead of >>>> spaces >>>>>>>> to >>>>>>>>>> avoid percent characters in url. >>>>>>>>>> 2) While in edit mode, change the title back to Pune University. >>>>>> Remove >>>>>>>> any >>>>>>>>>> - characters to make title clean. >>>>>>>>>> This is where confusion creeps in. >>>>>>>>>> >>>>>>>>>> If these two terms create confusion, why I need to show them both: >>>>>>>>>> I guess the *confusion is due to term Name*. It doesn't reflect >>>> actual >>>>>>>> usage >>>>>>>>>> of the term. URL or weblink or link or web address would be more >> apt >>>>>>>> terms >>>>>>>>>> to use to instead of Name. >>>>>>>>> >>>>>>>>> Regarding Page name vs Page URL. >>>>>>>>> >>>>>>>>> A bit of history: The reason we used page name and not page URL >>>>>>>> originally is because what the user is creating is a document in the >>>>>>>> database and initially it was called Document Name. Since that was a >>>> bit >>>>>>>> confusing for users, we had decided to call it Page Name. It just >>>>>> happened >>>>>>>> that the URL used was directly derived from the document/page name. >>>>>>>>> >>>>>>>>> In practice the 3 concepts could have different values: >>>>>>>>> * a value for the document’s name in the DB >>>>>>>>> * another value for the document’s title >>>>>>>>> * yet another value used in the URL. >>>>>>>>> >>>>>>>>> We’ve had discussions so that we could let the user provide shorter >>>>>> URLs >>>>>>>> for pages in the future. >>>>>>>>> >>>>>>>>> Now for the time being and since we don’t have this ATM, I think I >>>>>> agree >>>>>>>> with you that we could decide to display to the user the URL that >> will >>>>>> be >>>>>>>> generated (the encoded URL) and allow the user to change it. >>>> Internally >>>>>> the >>>>>>>> user would change the document name. >>>>>>>>> >>>>>>>>>> My users can differentiate between Title and URL. But the whole >>>>>>>> procedure we >>>>>>>>>> follow is certainly not understandable by all. And we definitely >>>> need >>>>>> to >>>>>>>>>> follow this whole long procedure, just to have short and clean >> urls. >>>>>>>>> >>>>>>>>> Yes, if you’re asking your users to care about the URLs that get >>>>>>>> generated, right now they need to be advanced users to be able to >> edit >>>>>> the >>>>>>>> page name in the Create Page UI (since changing the title afterwards >>>> is >>>>>> too >>>>>>>> cumbersome). >>>>>>>>> >>>>>>>>>> So, by showing both fields at the first place itself, I would like >>>> to >>>>>>>>>> shorten the procedure and url length. >>>>>>>>> >>>>>>>>> I’m in agreement with you. Let’s see what others think. >>>>>>>>> >>>>>>>>> Thanks for this interesting discussion! >>>>>>>>> -Vincent >>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> View this message in context: http://xwiki.475771.n2.nabble. >>>>>>>> com/Page-Title-and-Name-confusion-tp7603546p7603551.html >>>>>>>>>> Sent from the XWiki- Users mailing list archive at Nabble.com. >>>> >>>> >> >>
