Ticket #61 (new defect)

Opened 9 years ago

Last modified 5 years ago

Case insensitive CamelCase (Link creation, page loading)

Reported by: CyneBeald Owned by: unassigned
Priority: normal Milestone: 1.4
Component: core Version: 1.1.6.0
Severity: normal Keywords: CamelCase case-insensitive
Cc:

Description (last modified by BrianKoontz) (diff)

Not really sure if this is a bug, or a feature, or a feature request: the link creator doesn't really care if a link has the "proper" case for the page when it's used in a DB with case insensitive collation (actually, the page loader doesn't care either). As long as it's camelcase (and if you use a forced link, not even that), HomePage and HomepagE are both valid links pointing to the same page.

The problem is, how to solve that:

  • if you stop recognizing different casings as links to the same page, you might get links to create new pages that are called the same but have different case (very confusing, besides, you'll get into trouble with the DB wanting page tags to be "unique" in the sense "differing in something other than case"). If you don't want to have multiple pages with the same name but different case, you have to handle that separately.
  • Another option would be to ignore malformed links alltogether (probably more trouble than it's worth, users complaining about the engine suddenly stopping to produce links from camelcase words).
  • you could translate malformed Wiki Names into the proper case automatically (provided there's a page)
  • you could detect malformed wiki names when storing/previewing the page, and complain to the user so he fixes it himself
  • do nothing, the current system doesn't seem to have any real trouble with it, and as long as users don't start to deliberately use the wrong case for wikinames it's only a cosmetic deficiency

Related tickets: #191

Change History

Changed 9 years ago by dartar

  • milestone set to 1.1.6.1

Thanks for spotting this - interesting and delicate issue. My preference is for 3) but of course I'd like to hear what others think about this.

Changed 9 years ago by dartar

  • milestone changed from 1.1.6.1 to 1.1.6.2

Changed 8 years ago by DarTar

  • milestone changed from 1.1.6.2 to 1.1.6.3

Changed 8 years ago by DbieL

I am a bit confused as to the direction this is going. I fully understand the "problem" but the solution could have a serious impact on existing page names and definately affects future planning. I realize that coding for this will be involved and could be postponed; but the general plan should be fairly easy to layout.

Option 1: force all page names to comply with WikiName (CamelCase) format rules

Option 2: allow page names that do not comply with WikiName format rules (current situation)

Option 3: ??? It would be a great help to know what direction this is headed. The following is something I have written for our Wiki to explain the current "rules"

1) Type the name of the page you want to create in the your browser's address window (replace the current page name you are viewing with the name you want to create and add "/edit" at the end of the line. Note: spaces are not permitted. Using this method, page names do not have to be in WikiName format. What ever case you type the name in the address bar will be the case that will be displayed in the page index. If the page name is not in WikiName (CamelCase) format, then when you use it in a page and what it to appear as a link in that page, you will have to create a forced link. This is done by adding double brackets [[ ]] around the name. If a space is used in a forced link, anything in front of the first space will be considered the link name and anything after the first space will be the text that is displayed as a clickable link.

2) Clicking on a WikiName or forced link that has a broken underline under it (ExampleOfAWikiNameWithOutALinkedPage. The page will be created using the exact case format used in creating the link. Note: this may not be the same as the displayed name as forced links permit the display of a text phrase that may contain spaces while hiding the actual link name itself which can not contain any spaces (see above).

Note: WikiNames display differently in this comment field than they do in a standard Wiki page.

Changed 8 years ago by DbieL

Has there been any planning on this subject? I realize that DarTar personal web site makes use of non CamelCase page names. Would really like to see some resolution of this issue, at least in concept because of the possible negative impact on current pages that do not follow the CamelCase format.

Other pages on the subject: [ http://wikkawiki.org/rr]

Also refer to the following comment by DarTar: WaD, CamelCase is used to automatically parse words as internal links. Using only uppercase would result in a lot of false positives that shouldn't be parsed as links. It's for this reason that usernames must be CamelCase. This doesn't prevent you from creating pages with names like "lowercase" and create links to them via forced links:

Error: Failed to load processor lowercase
No macro or processor named 'lowercase' found

. -- DarTar (2006-07-03 03:04:57)


Changed 8 years ago by Nils (Uni)

Dbiel, the problem we have with page / user names is that we need a central regexp library because they are handled inconsistenly now. I am afraid nobody from the dev team had the time to do this.

As for the ticket itself: personally I like the current system which does not care about case sensivity. I do not know how others see this, but I never had the need to distinguish between ExamplePage and ExamPlePage (altuogh automatic correction could be a nice feature).

Changed 8 years ago by anonymous

Nils, thanks for the reply. My issue is not one of when or how long, but of what direction are we going to go in. It does not matter how long it takes, but if the goal is to require CamelCase page names, then it is stupid to start building pages that are not in CamelCase format. Personally I like the current usage that allows non-CamelCase page names. Having to use forced links instead of auto links is not a problem. The reality is that most single word names need to have forced links anyway as most people do not want to read a page that says ...... when you receive a BouncE message... but would rather see it displayed as .... when you receive a bounce message.... Or SmtP reads much better as SMTP

Changed 8 years ago by MasinAlDujaili

I'd prefer leaving all as it is right now. My Wikkas extensively make use of this feature (of case-insensitiveness). I'm using the extension for displaying the page title as link text if no link text is given. This way it's pretty nice to create links to pages like JTKirk by just typing JtKirk -- resulting in the display of the link text James Tiberius Kirk.

Who needs to have different pages like ExamplePage and ExAmplepage in one wiki?

Changed 8 years ago by BrianKoontz

Maybe the best way to resolve this is to create a system-level configuration parameter, say "permit_non_camelcase_tags", with the default set to 0. Store the display version of the tag in the DB for presentation purposes. So if a page is created as JtKirk, the tag is set to 'jtkirk' (or whatever the current protocol is), and display_tag is set to 'JtKirk.' The permit_non_camelcase_tags parameter can be used in cases where the formatter may need to differentiate between CC and non-CC display tags.

Changed 8 years ago by BrianKoontz

  • description modified (diff)
  • milestone changed from 1.1.7 to 1.1.7.1

Bumped to milestone 1.1.7.1 as there is already a closely-associated ticket addressing this issue as well (#191).

Changed 8 years ago by JavaWoman

  • keywords CamelCase added; camelcase removed

Changed 5 years ago by BrianKoontz

  • milestone changed from 1.2.1 to 1.3

Changed 5 years ago by BrianKoontz

  • milestone changed from 1.3 to 1.4
Note: See TracTickets for help on using tickets.