Feature Proposal: Allow numbers to be treated as uppercase instead of lowercase in WikiWords

Motivation

User experience is always subjective, but to me numbers simply look like uppercase. I find it pretty strange that they are treated as lower case by default. Year2000 looks like a WikiWord. Y2K doesn't.

Description and Documentation

Make treating numbers as uppercase a configurable option, so people like me can get the result they expect.

I patched my own install - a simple change to wikiWordRegex in Foswiki.pm (plus WikiWord doc changes). It would be nice if I could change a preference or config file option instead of re-patching after each upgrade.

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: LeilaPearson - 12 Sep 2010

Discussion

I like this idea, since it's configurable as an expert item and defaults to the current behavior.

-- GilmarSantosJr - 12 Sep 2010

There is a similar already accepted feature proposal. And with me as developer. The perl part is really trivial but I got stuck when I found I also had to change some JS and the JS regexes would depend on a configure setting.

The already existing proposal suggests to turn the numbers on and off a legal wikiname chars. But when we do it for sure the setting needs 3 values. Number (not wikiword char), lower case alpha, and upper case alpha.

Lower case alpha default like today.

With recent updates in how JS gets variables from perl I actually think I can figure out the JS part now myself.

If you permit I will no action this and merge it with my already accepted proposal in 2 weeks.

-- KennethLavrsen

Sounds great to me. Your solution is even more configurable, and I totally missed the JS requirement.

Anyone upgrading from anything prior to Edinburgh (don't laugh - I just did this at my new company should also appreciate the flexibility since numbers weren't allowed in wikiwords before then. I remember I'd patched my Dakar install to treat numbers as upper case, and was quite disappointed when Edinburgh came out treating them as lower case!

Thanks for including this option.

-- LeilaPearson - 15 Sep 2010

One more idea:

instead deciding wheather a number is lowercase or uppercase, accept both. Treat numbers both as lower- and/or uppercase, dependent on the case of the 'surrounding' caracters.

What I mean:

* accept Y2K as WikiWord and
* accept Year2000 as WikiWord

To me both examples look all right and obviously there are reasons for both ways. The question s, is there a reason against? Except the regular expression in the code becomes more complecated, but the focus should not be most simple implementation but most simply/comprehensive usage of the tool!

-- MatthiasThullner - 29 Sep 2010

I can imagine myself trying to explain this to a group of new users in a training session.

I do not think "both" is easy to grog. I think even I would be upset at times when words that I did not want as wikiwords become wikiwords. I get more complaints and questions about people trying to avoid wikiwords than people trying to make them.

Upper, lower, none - one of those 3 I can teach the users. But some magical mode where numbers are wikiword wildcards - that I think will be both confusing and create too many unwanted wikiwords. My 6 years as a TWiki/Foswiki admin and user support tell me that keeping things simple and rule based is the best.

-- KennethLavrsen - 02 Oct 2010

I must agree with Kenneth. I get far more support enquiries about preventing links than making them.

-- PaulHarvey - 02 Oct 2010

I support Kenneth and Paul. I seldom receive a question about making a WikiWord, but a lot of them asking "What is this question mark?", "How to make it disappear?"

-- GilmarSantosJr - 02 Oct 2010

Yes. I gave the "both" case some serious thought and it kind of made my head hurt. So I'd say the added flexibility in this case would add confusion without adding a lot of value.

-- LeilaPearson - 02 Oct 2010

I understand that, but I do not agree.

1. numbers are neither UpperCase nor LowerCase characters - they are different to both of them
2. I also get more questions about removing the question marks (but this is an issue with displaying the missing link as a question mark, which is a normal part of a sentence and therefor confusing, a different sign with a tooltip to explain it would be much better)
3. You get the question marks also with other WikiWords without numbers - so you have to explain it to new users anyway
4. Words with numbers a no 'natural' words anyway, so they are most likely something that is worth explaining it (in an extra topic)
5. I rate linking (and comprehensive navigation) over easy typing, therefore I like autolinking of WikiWords a lot and would like to push this further. Most non-power-users do not want to make links or use WikiWords (I have even seen a lot of topic names like 'Details' :-O ).
6. Humans are lazy, but they should be encouraged to think about a) the idea of using WikiWords with autolinking and b) creating another topic if it does not exist yet -> I think it is not always the best way to ask 'all users' what they want (democratically that would be using Word and Excel and store everything on a local drive - how to find that data again and how to distribute it to others is not their concern - could be done by email ;-> )
7. migration from LowerCase to both is easier than from LowerCase to UpperCase (only if you do not want to lose links, of course)

Nevertheless I can live with NumbersAsUpperCase, I also favor this to NumbersAsLowerCase (because I like to get as much autolinking as possible)

-- MatthiasThullner - 03 Oct 2010

Well, that's a good point - natural words certainly don't have numbers in them (at least in English). Still, I hope to publish some work before the end of the year which makes linking much easier (TinyMCE integration) - according to me, linking is still too hard for most new and casual users, WikiWords or not.

Perhaps it would be useful if we grep'd our data/ directories on live wiki installations to see how many words match a number-as-wildcard vs number-as-uppercase

-- PaulHarvey - 03 Oct 2010

This is very important to me, I support IBM Mainframes and much content has 8 character alphanumeric names which should not be a WikiWord.

-- JulianLevens - 07 Dec 2010

Guess this is accepted.

The thing I need help with to implement this is how to get the configure setting reflected in the Javascript code.

The perl part is very very easy. But the JS also needs to reflect same change and I am not quite sure how to do that.

Hint would be welcome from JS expert.

-- KennethLavrsen - 07 Dec 2010

Unfortunately I'm not a JS expert either - but I was wondering if this question relates to Tasks.Item8924. The discussion there seems centered around getting preferences values into Java Script. I agree this proposal can't be implemented without having the JavaScript also reflect the change...

-- LeilaPearson - 27 Oct 2012

Kenneth, I am a sort of Javascript expert, but I don't know what question you are asking from the above. If you could give me an idea of what you are trying to do, and what you have done so far, I'd be glad to help.

-- Main.CrawfordCurrie - 08 Aug 2016 - 14:16

Crawford. The task of adding a config option to Foswiki and change the regexes that defines the WikiWord is simple. And that is why I volunteered to do that. It lies within my limited skills and it is all Perl

But as I dug into the feature I found that the WikiWord definition is also defined and hard codes several places in the Javascript code in several places and it has changed a lot the recent few years.

So in order to make this feature work we need the perl code to tell the Javascript code the correct Regex needed to define a wikiword. And the way the JS is written and with the libraries like JQuery I am a bit out of my league. I tried but got stuck in not understanding the most basic JS syntax.

I am sorry I am such a bum-head with Javascript.

-- Main.KennethLavrsen - 15 Aug 2016 - 13:19

This feature proposal is in limbo state for long enough with its once committed developer having lost interest in it. As such this one is free to be picked up by anybody. But until then we have to downgrade and park it.

-- Main.MichaelDaum - 20 Feb 2017 - 14:18