archive-org.com » ORG » W » WIKICREOLE.ORG

Total: 1035

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Talk.Common Text Elements
    they look the same for example LaTeX is going to render the formulas with its special fonts that are very different from the browser s ones for example It also saves the users learning new markup and thinking of several ways to achieve the same effect in different context they can just copy and paste I agree that a wiki should provide features needed by its community for a scientific wiki a LaTeX or very similar extension is simply a must I even listed a proposed markup in the HintsOnExtending the same that is used in LaTeX for embedding math x 2 I believe it is at least as easy to type as x 2 and has several additional benefits the symbols appear exactly as in formulas being distinguished from the main text the markup is identical to that in the formulas and you can even copy parts of the text directly to from your LaTeX sources Plus the risk of any collisions or surprising effects is much lower On the other hand a wiki dedicated to different topics like gardening will be much better off with just a simple filter converting commonly used phrases like m2 m² or h2o H₂O As long as they are readable in the source form the interoperability doesn t really suffer I always like to bring up the Sensei s Library as an example of a wiki that has its markup adopted to suit the needs of its community One can hardly imagine such an extension in a core specification for all the wikis in the world Many markup languages to which Creole is going to be translated mostly HTML expect some degree of semantic or at least screen reader friendly markup like indicating the LanguageOfText and marking AbbreviationsAndAcronyms on the other hand if Creole is going to support all useful HTML features I d rather use directly HTML whose syntax is more consistent What about proposing in Additions to reserve single angle brackets for HTML Typically it would be filtered to avoid abuses YvesPiguet 2007 Sep 20 Yes I tried to use neutral language as much as possible Note however that there are use cases of both denoting the language and using abbreviations in wikis so I think it s worth our attention possibly to be dismissed but at least discussed before that As to mixing HTML with wiki I have two objections on two different levels The and characters will appear in any technical text randomly on their own both surrounded by digits and by letters Sure in a perfect world they whould all be in a or but wikis are not perfect worlds Reserving single character without any additional context like only at the beginning of a line is imho a very bad idea Once you allow HTML you can white list it so it s fairly safe all advanced users will be using HTML and the page will become read only for new wiki users the exact opposite of the

    Original URL path: http://wikicreole.org/wiki/Talk.CommonTextElements (2016-02-11)
    Open archived version from archive


  • Talk.Comparison With OLPC Markup
    Home Talk ChristophSauer Home Talk CodeHighlightingProposal Home Talk CollisionFree Home Talk CommonTextElements Home View Page Discussion V iew A ttach I nfo The example for image markup uses the unfortunate format which will confuse people Better use or or something like it I m also confused about the unordered list example Is the example from pre 0 1 days and should be changed AlexSchroeder Fixed both I wonder about the

    Original URL path: http://wikicreole.org/wiki/Talk.ComparisonWithOLPCMarkup (2016-02-11)
    Open archived version from archive

  • Talk.Complex Tables Proposal
    to make a syntax proposal 3 Given that this set of functions is prospective that is it s not been implemented by any wiki engine to my knowledge is it inappropriate for WikiCreole org to broach this prospective topic I m interested in the answers to 2 3 prior to moving forward Thanks JohnMcClure 23 Sep 08 There are people who monitor the changes at least one myself but the interaction level has decreased since Creole 1 0 was released Your questions will be answered in the next few days Thanks for your interest in Creole and for your participation YvesPiguet 2008 Sep 24 1 What do you mean by group 2 No there are lots of people with lots of ideas although it s been quiet lately The huge amount of possible ideas is was one problem of this project actually 3 It s not really possible to discuss usability and user experience related topics without at least minimal testing Building and testing prototypes should be in my opinion an important part of the design process especially with new things RadomirDopieralski 2008 Sep 26 1 I saw begin a group button somewhere on this site I m not sure what that is about 2 My hope is to see palpable interest in crafting Creole 2 0 now that 1 0 is published It s difficult to discern whether or not the group has implicitly concurred that its work goals have been substantially reached There is precious little talk about 2 0 on this site 18 months ago the question was broached but not answered The 1 0 specification explicitely says frozen and no development for two years And ultimately there couldn t be any after full two years of no moving So if there s no chance for a

    Original URL path: http://wikicreole.org/wiki/Talk.ComplexTablesProposal (2016-02-11)
    Open archived version from archive

  • Talk.Creole 0.1
    why I would prefer generaly to ignore any sequence of Blahma That would rule out any emphasized headings with a colon My current approach in the moin parser is just to match the URLs with a whole list of protocols before the italicss RadomirDopieralski 2006 09 08 The case for using asterisk rather than dash for bulleted lists a dash for bulleted list is not collision free it collides with for rule when lists are nested 4 deep It also collides with 3 dashes for rule which is used by some wikis including TWiki which is signing up for Creole b asterisk for bulleted list is collision free Actually I think it was probably the mistaken belief that asterisk for bulleted list would collide with asterisk for bold that caused the decision to use dash How is the collision avoided Fairly simply by using the rule that lists must be of the form space list item and that bold is of the form nospace bold The possibility of a collision only occurs for lists nested two deep c The collision is successfully avoided by the five most popular commercial wiki engines with markup Confluence PBWiki Socialtext Wikispaces and StikiPad they all use for bulleted lists and either or for bold d All of the top 10 open source wikis that use or for bold also use for bulleted lists TWiki DokuWiki and PhpWiki e is almost universally used for bulleted lists Of the 59 wikis on wikimatrix that have markup for bulleted lists indicated 46 use and only 3 use Sorry my late posting I ve only just stumbled upon this site MartinBudden 2006 09 10 I also recently found out that dashes will interfere with the I usually put in front of my signature in wikis RadomirDopieralski 2006 09 10 I ve rememberted another minor collision as well is sometimes used for emdash MartinBudden 2006 09 11 Here some nitpicking by me I know that some of the following points are special cases However I think that a good spec should be clear about these cases Even if the behaviour is intentionally undefined i e implementation defined it should at least contain that intention as statement First in the example about pre in lists the three braces are separated by a space and still recognized as pre I think this isn t correct but a restriction from this wiki engine is it But then please put this information in a note Furthermore I would like to see a clean separation between block and inline markup In the case of pre the current spec says that it works inline or as a block However there is no way to disambiguate both cases at the beginning of a line My suggestion is to differentiate between both cases as follows A preformatted block is started by on its own line The content of the block starts on the next line can span multiple lines and is closed by the next on its own line On the other hand inline preformatted text starts immediatly Hence it is always followed by some text Preformatted block Inline preformatted text My last issue are line breaks For me it is not clear whether line breaks are supported in e g lists or not Is this a single list item or a list item followed by a paragraph There is a similar problem with line continuations For example the spec is clear that n o linebreaks are allowed within headings However does line breaks here mean physical or logical line breaks logical after processing line continuations In other words are line continuations allowed in headings although line breaks are not Is that a single heading or a heading followed by a paragraph The section about line breaks and line continuations is not very helpful about that I hope I could give some constructive remarks OliverHorn 2006 09 10 Comments on use of for image I m afraid this is not collision free is used by MediaWiki for templates And MediaWiki is the most popular open source wiki by your charts Given the widespread use of templates in Wikipedia I think it would probably be impossible for MediaWiki to adopt this syntax for images As an alternative may I suggest the practice which is commonly used by many wikis namely augmenting the link syntax with either image or img I think img is preferable as it is more language neutral this leads to the image syntax being img foo jpg and img foo jpg title MartinBudden 2006 09 11 Hi a It does not matter and in fact img is a violation of the basic principle of making the markup language independent You see if you see image inclusion as a just a special case of transclusion you ll see that templates and images can be embedded using the exactly same syntax It s just up to the WikiEngine to figure out what the media type is and include it appropriately MediaWiki just puts all the images in the Image namespace which makes it really easy for MediaWiki to support this b In fact I believe this syntax was suggested by BrionWebber the lead developer of MediaWiki And if he doesn t think there s a problem I m inclined to agree JanneJalkanen 2006 09 11 Yes it was suggested by BrionVibber MediaWiki will probably implement Creole in the Edit Creole mode instead of mixed mode At least that s what Brion had in mind i think Christoph 11 Sep 2006 In reply to a above my comment was made in accordance with the goals stated on this site the most important goal was being collision free whereas the avoiding Text Tags principle of I18N goal was only 12th in priority In reply to b above I should have explained myself more clearly When I said it would probably be impossible for MediaWiki to adopt this syntax I did not mean that it would be impossible or even

    Original URL path: http://wikicreole.org/wiki/Talk.Creole0.1 (2016-02-11)
    Open archived version from archive

  • Talk.Creole 0.1 Test Cases
    could also write a Latex converter for this Do we need output examples for this as well Wheres the end to this Creole describes a Model of a Document i don t think it should be tied to closely to any representation It s a novell you make the movie out of it We don t tell you the script for the movie Just make it so that People like it I don t judge your implementation on wether your XHTML is exactly I just will tell you if i like what i see Just as i don t judge a movie on how closely it is to the book I think creole should give implementers creative freedom to interpret it Christoph 06 Aug 2006 Why do the test cases feature nested lists AlexSchroeder No specific reason i just don t do that usually thats why i personally have no clue how it should be rendered or what would be logical As soon as something comes into my mind I add it In the meantime please feel free to add stuff you would like to have tested and working by yourself but don t make it too big We could have a common Things people usually do testcase and a Horrible things that people might do testcase if you like Christoph 06 Sep 2006 Well I have my own test cases you can find a snapshot on Talk Oddmuse The suggested XHTML output on the ordinary pages is good enough AlexSchroeder Yes those testcases are more like for people like me wandering around in wikiland visiting the sandboxes and see if stuff works i need Blackbox dummytests that i will improve incrementally as i learn more what does not work ChristophSauer 07 Sep 2006 I m implementing a Creole parser

    Original URL path: http://wikicreole.org/wiki/Talk.Creole0.1TestCases (2016-02-11)
    Open archived version from archive

  • Talk.Creole 0.1 Test Cases 2
    rights reserved license BY SA Sponsored by the Wiki Symposium and the Nuveon GmbH view find Quick search type ahead Recent Searches Clear Talk Creole 0 1 Test Cases 2 Your trail Home Talk ComparisonWithOLPCMarkup Home Talk ComplexTablesProposal Home Talk Creole0 1 Home Talk Creole0 1 Talk Creole0 1TestCases Home View Page Discussion V iew A ttach I nfo Is there any particular reason why this very wiki doesn t

    Original URL path: http://wikicreole.org/wiki/Talk.Creole0.1TestCases2 (2016-02-11)
    Open archived version from archive

  • Talk.Creole 0.2
    0 2 violates Goals In particular Using for pre is not collision free is used by MediaWiki for templates This is a huge collision it would prevent Creole co existing with MediaWiki probably the most popular wiki of them all Being collsion free is the number one goal Using for images This violates goal 4 Not New According to wikimatrix no wiki uses for images Using for images is not collision free it collides with TiddlyWiki s use of for macros MartinBudden 2006 10 08 I see that some changes have been reverted and so the previous comments should be considered resolved But I ve noticed that the syntax for placeholders is still different form previous version x Is it intended or simply forgotten Apart from this I would like to see quotations and simple tables included into Creole 0 2 From my point of view they would make Creole much more useful I see there s some discussion about tables but nothing about quotations This is quite surprising I think the chosen goals are reasonable and important and the proposed syntax is quite good for satisfying them But probably now having some use cases would help a lot MicheleTomaiuolo Changing the placeholder syntax back to Creole 0 1 was just forgotten Sorry about that ChuckSmith I read Any markup within a link will not be parsed Is it necessary to specify this I would say this is in contrast with the ExtensibleByOmission goal Moreover in Images there are examples of images inside links which is a special case of markup inside links Thanks 2006 11 06 MicheleTomaiuolo Please give a bit more notice before declaring something final On Nov 9 you stated that Creole 0 2 would be declared final on Nov 11 Two day s notice is hardly enough it s only sufficient for people who read the site every day and even for them it assumes they have time to comment on any given day MartinBudden 2006 11 13 Well it was just a minor change but you are right We should agree on a ReleasePolicy but right now i don t have a clue how it could look like Maybe you could post links to other release policies so that we could learn from them ChristophSauer 2006 11 14 Martin when would you suggest be the final date before declaring Creole 0 2 final It really is only a very minor change and has been on the site for a month now for comment ChuckSmith 2006 11 14 I m not asking for you to not declare Creole 0 2 final after all you are still accepting comments on 0 3 merely that in future you give more notice I suggest 2 week s notice for a 0 x release and at least a month s notice before you declare Creole 1 0 final MartinBudden 2006 11 16 Errata I found an error in the section Bold Italics Links Pre in Lists The last list item

    Original URL path: http://wikicreole.org/wiki/Talk.Creole0.2 (2016-02-11)
    Open archived version from archive

  • Talk.Creole 0.3
    enabled or disabled preformatted block inline seems the simplest way to go Not allowing bold italics etc but allowing images in headings just seems an unnecessary complexity to a parser for no real benefit JaredWilliams 2006 12 14 Images in headings Where checks the specs and the discussions Ok now that s a straight fantasy On the Headings page there are even examples of unacceptable in Creole combinations and they include links and images inside headings So it s as consistent as it gets no markup in headings This makes it extremely easy to fish headings with a single regular expression without any need for a stack or multi pass parsing Besides what semantic does an image in heading have Sure there are those books with illuminations and stuff but that s rather a question of style Smileys Non unicode symbols maybe RadomirDopieralski 2006 12 14 My apologies I think I ve been reading too much about various markups or something Just reviewing my own creole parser written a while back and it does not parse markup within headings But as for why would want to have images inside headings if images are not shown on the client then the alternate text may need to be a heading Whats also confusing the issue is that I ve expanded the meaning of to perform general inclusion transclusion For other things like csv plain text wiki pages or parts of and google maps So thinking wether inclusion into headings should be allowed JaredWilliams 2006 12 14 Well Creole is supposed to be extensible so you can create additional rules like that and it s still compatible But I think we shoudn t require csv parsing or concrete ways of handling transclusion from the wiki engines they are just so different in this regard Maybe there could be recommendations saying that if the engine has it the markup should be like this RadomirDopieralski 2006 12 14 I believe the 0 3 spec is incorrect incomplete in its description of table headers When announcing the 0 3 spec Chuck mentioned header cells being seperated by double pipes see http www wikicreole org wiki News blogentry 011206 1 Unless I m blind I still don t see this mention reflected in the spec MartijnVanDerKleijn 2006 12 15 The spec is inconsistent with regards to the use of bold and italic Under the heading for bold and italic the spec states and one should be able to make links bold and italic which I assume to mean it should be possible to use for example the bold markup inside of a link markup This directly contradicts the remark under the heading for links which states Any markup except for images within a link will not be parsed Either the spec needs to be more consistent on this point OR the if my above assumption is incorrect the text needs to be clearer on what it means I vote to not allow markup inside a link by

    Original URL path: http://wikicreole.org/wiki/Talk.Creole0.3 (2016-02-11)
    Open archived version from archive



  •