Add a new option to disable CamelCase links, per wiki or per page.

WikiNames are very appropiate for English, but for others languages are not. I.e.: in English HelpContents is in Spanish ContenidoDeLaAyuda that is very ugly. For a technical use is ok live with WikiNames but for CMS like webs they are bad. Then I propose an option for disable WikiNames and leave alone the ["wiki names"] notation. Also as a page by page option (#Format:DisableWikiNames). I have a Intranet wiki about Delphi programming and ours code snippets are fulled with DataSet, BeforePost, etc. like words and this proposal can help. -- PereMartinez 2004-02-18 23:16:00

I'll second this proposal. In Finnish, it is bad form to either capitalize letters in mid-sentence (much less mid-word) unless the word is a given name. Finnish also uses a lot of compound words, for example "Table of Contents" is "Sisällysluettelo" (literally, contents + list), and thus Finnish titles for pages often only have one (long) word. It would again be bad form to capitalize the "luettelo" (list) part to make a WikiName out of the word.

A couple of other factors also make Finnish not very wikiable: Finnish has a large number of word forms, which not only include suffixes to the words, but may change the last few characters of a word. For example, the genetive form of the word "ehdotus" (proposal) is "ehdotuksen" (the proposal's). The suffixes are also appended to abbreviations with a colon in between, so "FEP:iin" (into the FEP) would be interpreted as an InterWiki name. This completely screws up the abbreviation: FEP:iin.

-- TomiJunnila 2005-01-17 13:47:31

• Alexander Schremmer wrote: Do you think that unescaping such non-WikiNames using ``, '''''' or ! is a big problem?

  • Quite frankly, yes. It's not a big problem for me, really, but other users don't like having to often rather unintuitive control sequences in the text relatively often. The ! escaping doesn't work for InterWiki links, the backquote is difficult to type on Finnish keyboards (shift+quote, then space), and six single quotes is rather long. Furthermore, the sequences detract from the readability of the raw text, which is something I hear complained rather often.

• I am not too happy with admin configurable wiki markup. Besides the technical problems mentioned above, this creates the problem that moin wiki 1 uses another markup than moin wiki 2. And users wonder, why CamelCase works or why it doesn't work.

• Or, when admin switches after already having data in the wiki, links show up or vanish because of that.

• Also our help pages use CamelCase links, switching it off would make help unusable.

• For a general move away from CamelCase, we would need a migration script, converting all CamelCase links to free links.

• You see: lots of troubles. So my current state of mind is rather to remove markup configurability, not add more config switches. I am neither a fan of CamelCase, nor of free links. I am rather emotionless on that topic (I know people who aren't). But both have advantages and disadvantages and is not at all clear what's better. Until it is clear (or until another technology makes this a non-issue), I think I won't change anything in that regard. -- ThomasWaldmann 2005-01-18 18:39:59

  • Allowing users to choose to the extend of linking syntax does not harm MoinMoin in any way IMHO. -- AlexanderSchremmer 2005-01-18 21:35:57

  • Thomas, your points are valid in general. There is, however, an advantage to having the CamelCase links admin configurable: if most pages on a wiki are in a language which isn't really WikiName compatible, it can be handy to have CamelCase links disabled by default. However, in this case we would need to be able to re-enable them on a page by page basis if we don't want to convert all CamelCase links to free links. Then, the underlay pages could include the page-level control to enable CamelCase links regardless of the admin setting.

    • However, I think that since most often the admin could just add the #disablewikinames verb to the page templates, the config setting isn't really required. -- TomiJunnila 2005-01-18 20:46:10

Solution

See ParserMarket

• IMHO we should ship it and point to it from somewhere in the documentation. -- AlexanderSchremmer 2005-01-19 23:03:40

Problems

Both alternatives here create a chaotic situation, when same wiki has more then one markup. On the help pages, old style CamelCase, and on the rest of the wiki, new extended links. Also users that used to another moin wiki will not understand why their markup does not work on the modified wiki. Most users does not know anything about the #format processing instructions, and they don't need to. Wiki is about quick and easy editing, learn few markup rules and write.

We should discuss this issue as part of moin new syntax, and not introduce new half made solutions we will have to be compatible later. Any one can use custom parsers (as Florian suggested) on his wiki, but we should be very careful with features we add to the main distribution.

-- NirSoffer 2005-01-19 14:13:53

• I don't think the situation is quite as chaotic as it might seem at first:

  • The usage of the alternate parser would probably only be used by a relatively small minority of special wikis, especially if the documentation for the option is well hidden and marked with huge warning signs about the consequences of using the option. For example, I would use it on only one of my wikis, where the content is very much CamelCase-incompatible (relatively formal documents, a lot of abbreviations, and in Finnish). The users on the wiki would know about the change, especially since changes to the wiki are restricted to this small user group.

  • Having the #format processing instruction "standardized" (by being part of the distribution) would limit the chaos because (admittedly, only the knowledgeable) users would know exactly what to do if they want to change the processing to one or another.

  • When editing an already existing page, the links on that page will give a good idea of what will work.
  • One would also assume that the admin that chooses the different default parser would also modify at least the quick help below the edit area. (Of course, if this part was chosen according to the format of the page, that would be great but probably far too much work.)
• I do, however, agree that the best option would be to consider this as a part of the new syntax, iff we're in the process of actively planning one.

  -- TomiJunnila 2005-01-19 19:02:50

I could imagine to add this instructions in an extended and more general way to our documentation. A subpage of HelpOnConfiguration or HelpMiscellaneous/FrequentlyAskedQuestions are candidates. I think we should not include any modified wiki parser in the distribution to signal that we do not recommed this and not to enable the parser in a standard installation. Copying 5 LOC of Python code should be easy enough for everyone. -- FlorianFesti 2005-01-19 10:43:23

• If the distribution included the nocamelcase parser, it would effectively standardise the format name (at least inside MoinMoin), which I could see as a benefit.

• However, since the nocamelcase parser is dependent on the normal wiki parser, changes affecting the main parser might affect ParserMarket/NoCamelCase also, which is not nice from a maintenance perspective.

  • The correct solution is subclassing. That will solve this issue. At least I have a parser that does not depend on the internal structure of the wiki.py parser. -- AlexanderSchremmer 2005-01-20 23:03:52

Try to make a wiki page fill with name like McDonald, McCarthy, McLane... and you will want to disable CamelCase / WikiName. It would be nice if MoinMoin automatically disable CamelCase / WikiName highlight and link creation if the page does not exist. BTW, users spend their time giving valuable feedbacks that can help improve MoinMoin... please don't delete this page. -- nj

Hi, see my changes to your text. Many people like to create new pages the way you like to avoid it. The solution is to use a ! -- ReimarBauer 2007-11-03 07:40:42

The "!" is definitively NOT an optimal solution. Do you know how ridiculous all the yellow "!" look in the GUI editor? It is very confusing and a lot extra works for users which is NOT a good way to get people to use the wiki. WYSIWYG just lost it meaning right there. And when you want to use Raw Text for custom css or pdf exporting, you get all the unwanted “!”. Some people will find CamelCase / WikiName useful, some will not. Why not give people the choice / option to disable / enable this feature? --nj

• per user or per wiki?

I moved the interesting part to the ParserMarket. I would suggest to delete this pages as it only contains personal views that I don't think we'll get together to a consensus. -- FlorianFesti 2005-01-20 08:00:54

Please do not delete this page as it contains personal view of wiki users that we do not want to loose. -- NirSoffer 2005-01-20 12:33:31 -- ReimarBauer 2007-11-03 07:40:42

CategoryFeatureRejected