Feature Proposal: Optional remove restriction that first character of Web / Topic be upper case.

Motivation

There are times that forced capitalization of topics just doesn't work for the particular application. This was requested in Support.Question1913

Description and Documentation

With full support for Unicode, and possible unicameral languages, forcing the first character of topic or web names to be "upper" doesn't make sense. However this will definitely break existing wiki's, so this needs to be a configuration option.

Examples

[[derKezarian]] should result in a topic named derKezerian and not DerKezerian

Impact

This breaks any explicit links that depend upon auto-capitalization. For example [[a new topic]] will link to ANewTopic. If this feature is enabled, it will link to either aNewTopic or possibly anewtopic. So this option must not be enabled on an existing Wiki, without careful consideration.

WhatDoesItAffect:	%WHATDOESITAFFECT%	edit
Configure	Add new option, with a warning, that enabling the feature can cause issues.	edit
Foswiki::UI::Rename	Eliminate ucfirst of the topic name	edit
Foswiki::Render	Eliminate auto-capitalization of [[ link generation ]]	edit
Foswiki::Request::*	Eliminate the force ucfirst done in the URL parsing	edit
Topic sorting	Currently we do a simple alpha sort on NFKD Topic name. Once lower case topics are allowed, this results in sorting ABCDE...XYZabcde...xyz which is confusing. Lower case topic names sort at the end.	edit
Javascript	Web topic creator needs to not force first character to upper.	edit

Implementation

Add configure key: {Feature}{EnableLowerCaseTopics}, which conditionally disables the ucfirst call for topic and web names.

Add an lc() call to the sort cmp operation for topic names in Store and Search. This makes the sort results appear much more natural. The issue exists today, but it's not as obvious with the first letter forced to upper.

Add a Preference setting:

• Set LINKAUTOCAPITAL = 1

If disabled then rendering of [[square bracket links]] will not do any auto-capitalization. The topic name will have spaces will be removed, but no upper case transition.

The code changes are all quite minor.

-- Contributors: GeorgeClark - 17 Jan 2018

Discussion

Alternative solutions

The DBCachePlugin and activation of the Topic Title somewhat mitigates the issue by allowing the desired name to be stored in the Title metadata.

-- GeorgeClark - 17 Jan 2018

If possible, I would suggest that there is an option for the option to control this effect on a Web-basis, and not only globally. I know I'm being selfish here, but this request is only needed for one Web inside my wiki.

Another suggestion: if ucfirst is disabled, and an existing link would not work, you could add an option to go to the same page with a different case: If you don't find "Foo", then go to "foo".

-- LieVen - 17 Jan 2018

There are two implementation areas:

1. URL based Web & Topic forcing to ucfirst. This would be a system-wide configuration option. If enabled, the URL becomes will be literally used, without any transformation.
2. Rendering control of [[link text]]. This makes more sense to be a Site/Web/Topic configuration option. LINKAUTOCAPITAL, defaults to true. Unlike the NOAUTOLINK setting, there would not be an equivalent to the <noautolink> block. With LINKAUTOCAPITAL = 0, anything entered within the [[square bracket links]] would be converted to a topic name without any capitalization. ie "squarebracketlinks". If you want a different results, you would need to use the [[squareBracketLink][square bracket link]] style.

There is a related possibility, should even spaces be removed. There have been requests to permit spaces in topic names. I don't want to complicate this proposal with any growth into that feature.

Regarding auto-resolution of case errors when searching for a topic, there is considerable discussion around an old TWiki proposal TopicCaseSensitivity that would apply. Rather than simply URL and link rendering, this work would be down in the Store and would have much deeper impact. I'll leave that feature out-of-scope for this as well.

-- GeorgeClark - 17 Jan 2018

Another issue with supporting lower case web / topic names, would be possible collisions with the Foswiki installation directory structure. Any directory names would have to be "reserved" Web names.

One possible solution I've tested would be to move the Foswiki webroot down a level

 Foswiki
 - bin
 - data
 - lib
 - locale
 - templates
 - tools
 - working
 - webroot
   | - pub

This has the added benefit of being a more secure deployment. It obviates any need to protect individual directories. However it would need some adjustments relative to Tasks.Item14530 (Setting a "RootDir" config variable).

It does require some adjustments to bootstrap. Probing for an alternate pubdir location resolves the issue.

-- GeorgeClark - 30 Jan 2018

Thinking about the [[spaced link ]] and auto-capitalization, I think the solution is to detect if the link does contain embedded spaces, and if true, do the full auto-capitalization including the ucfirst. But if it does not contain embedded spaces, treat it as-is.

This eliminates the need for a LINKAUTOCAPITAL preference. That would ensure maximum compatibility with older Foswiki.

-- GeorgeClark - 07 Apr 2018

First of all: Thanks a lot for considering my request. I really appreciate it. Here's a beer: c|_|

Next, I have a question (or a suggestion to consider): does this change consider case sensitivity?

1. will it be possible to have both pages "Foo" and "foo", and link to them like that?
2. If I make a link [[aaF]] will it link to the new page "aaF" or "aaf"?

-- LieVen - 09 Apr 2018

No it does not change case sensitivity. That actually depends on the underlying file system. On a Linux system where the file system is case sensitive, [[Foo]], [[foo]], [[aaF]], and [[aaf]] would be 4 distinct topics. On a Windows FAT based file system where it is not case sensitive, [[Foo]], [[foo]] would be the same topic, and similarly for the aaf / aaF names.

I'm not sure how this would work on other server platforms.

-- GeorgeClark - 09 Apr 2018

It isn't just FAT that is not case sensitive on Windows. NTFS is also not case sensitive.

-- MichaelTempest - 09 Apr 2018

Commenting is disabled while not logged in