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.Additions
    Practices Ambiguities IRC Meetings External Discussion Promotion Recent Changes Talk Index wiki node Sandbox Copyright C by the contributors Some rights reserved license BY SA Sponsored by the Wiki Symposium and the Nuveon GmbH view find Quick search type ahead Recent Searches Clear Talk Additions Your trail SystemInfo Home Talk 19JunMeeting Home Talk AbbreviationAndAcronyms Home Talk AccessControlLists Home Talk AddNoWikiEscapeProposal Home View Page Discussion V iew A ttach I nfo

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


  • Talk.Aims
    not have their font installed it was a total mess and then I pointed out that many of their customers were getting the same very amateurish looking text The problem was that the company was telling the customers how they had to read the emails They weren t letting the customers pick the best font for them did they care if someone had poor eyesight and so wanted to read emails with a particularly clear font the company didn t care and so didn t want their business Unfortunately without html some of the very common formatting isn t possible It really is annoying not being able to emphasise part of the text And so many times I ve tried to put things in a tabulated table knowing that only if people happen to use the same font will they see it the same So what we need is a specification that lets people emphasis text without telling them how to display it ONe that doesn t insist you have Micro oft fonts installed on your spectrum PC but which lets you EMPHASISE So I am suggesting that creole should be a relative specification That is to say the specification says how parts of the text relate to each other not how those parts will be displayed absolutely ABSOLUTE Times New Roman Red 12point pica position on screen Code Relative stronger emphasis different from the rest of the text more important raised up smaller text included as a note how the note is displayed is absolute included as a quote how displayed is absolute Tables describe the relative layout of items The meaning of underline Having said Creole provides a meaning rather than a format I wondered what that meant Underline is a form of highlighting that leaves the characters displayed as is It shows the text is important without making the text stand out Indeed in some sense it reduces the prominence of the actual letters a bit like making a flower more prominent by putting it in a bigger flower pot The emphasis is the meaning not what is said Bold unlike underline makes the characters more prominent It The equivalent of having the same size flower pot but with a bigger flower Bold is like shouting without saying anything more important Italic does not affect the prominence of the text it differentiates the text without applying emphasis Strike shows the negation of the text the sense that the text should not be there Superscript is a meaning applied to the text like a sum squared Subscript is a meaning subsidual to the full sized text THE TEST What would creole sound like if it were spoken and not displayed Underline deepen the voice slow down so as to speak with more authority Bold make louder speed up Italic adopt a new character e g an accent Strike Superscript raise tone of voice Subscript lower tone of voice Citing Insomania which implicitly suggests Creole is not so much

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

  • Talk.Alain Desilets
    Sandbox Copyright C by the contributors Some rights reserved license BY SA Sponsored by the Wiki Symposium and the Nuveon GmbH view find Quick search type ahead Recent Searches Clear Talk Alain Desilets Your trail Talk AbbreviationAndAcronyms Home Talk AccessControlLists Home Talk AddNoWikiEscapeProposal Home Talk Additions Home Talk Aims Home View Page Discussion V iew A ttach I nfo Welcome Alain We are very happy to have an usability expert

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

  • Talk.Alex Schroeder
    view find Quick search type ahead Recent Searches Clear Talk Alex Schroeder Your trail Talk AccessControlLists Home Talk AddNoWikiEscapeProposal Home Talk Additions Home Talk Aims Home Talk AlainDesilets Home View Page Discussion V iew A ttach I nfo citing you h1 supported although I believe it to be wrong Mee too maybe we should get rid of it again At the time we accepted it I didn t see the

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

  • Talk.All Markup
    by the Wiki Symposium and the Nuveon GmbH view find Quick search type ahead Recent Searches Clear Talk All Markup Your trail Talk AddNoWikiEscapeProposal Home Talk Additions Home Talk Aims Home Talk AlainDesilets Home Talk AlexSchroeder Home View Page Discussion V iew A ttach I nfo I would love to have a current canonical definition of the markup One that a student of us can simply implement It s fine

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

  • Talk.Alternate Link Syntax Proposal
    forget about that whole title alternate text thing that is not what I meant I just want to make the order less relevant My points are Explicit vs implicit links Implicit links are not showed in the Links page as they are on the Creole 0 3 page Even if it breaks the Extensible by omission principle a little should Creole standardize the different syntaxes of targets especially for implicit links so that nothing breaks when exchanging Wiki texts Internal target InterWiki target URI RFC3986 If the spec does not make the syntax of targets more formal I think it could generate collisions with the chosen markup and delimiter whatever they are When you look at WikiMatrix internal external links comparisons the meaning of the description part of the link changes somewhat between internal and external links and the position order of the description in the link If Creole accepts any order it could generate ambiguous situations but make the order less relevant So let s try again I have one existing wiki page called Foo Foo Bar would generate Bar I have one existing wiki page called Bar Foo Bar would generate Foo I have two existing wiki pages Foo and Bar Foo Bar would generate Foo hyperlinked text is the first part of the link by default The questions are How could Creole make the third example less ambiguous if the order is not relevant In the first example a problem arises when someone creates a page called Bar afterward The rendering will change for the one in example 3 Is that OK What if the markup delimiter is part of the Text or Target That s a recurrent question for any markup So IMHO we have a couple of things to settle Creole support of implicit links The order of the text and the target should we care The markup itself and the field delimiter pipe I think we have a consensus on that point How formal the syntax of the target should be EricChartre 2007 01 02 Thank you for your clarification I think I understand it better now Personally I m still somewhat charmed by the mentioned before here approach you suggested recently defininng only the absolute minimum we really need for interoperability and disambiguing things and leave as much detail as possible to the implementers On the other hand I agree that the details you mentioned can be problematic and thus should be defined We can take the following approach For URLs in text without any markup use somewhat generous matching algorithm for example a regexp like w S s Obviously this is not correct implementation it won t match legitimate urls ending with a comma or dot and such and it will match more url like things that are really defined But it follows the usus People often put commas or periods or other punctuation right after the ulrs in the text At the same time sane URLs rarely even use these characters except the dot not to mention ending with them you can always use the markup to force them For the URLs in links with the markup I d say that anything that matches w is an URL external link while anything else is a page name some wikis can also check the validity of the page names and refuse to parse malformed links of course The text and target order problem is in my opinion impossible to solve without introducing a totally new markup for links so that it doesn t collide with existing ones As you noticed your approach can change the links of an existing document it may be an old and established wiki page and the change can make it say something totally different than before and the change won t even appear in the recent changes That pretty much breaks peer review one of the most fundamental mechanisms in wikis The used order has an additional advantage since the character is forbidden both in URLs and in most wiki page names you don t need any kind of escaping and you can freely use additional pipe characters in the link text It would be impossible the other way around What do you think is it enough RadomirDopieralski 2006 01 02 One thing that w would limit is mailto think news too links JaredWilliams 2006 01 02 Questions First I wondered why the creolemarkup wiki doesn t follow it s own rules but now I think it s maybe not possible to develop a new standard and use it at the same time Is this the reason For example To set an external link the markup is very uncommon Daniel Brüßler info danielbruessler de the link name http www the url org Welcome Daniel to Creole Wiki Indeed the Creole parser for JSPwiki is being developed but slowly In the mean time we try the markup on a number of Wikis using Engines that already have at least partial Creole support Obviously having to convert all the pages every time there is a change in spec would be very uncomfortable For now we must bear with the non standard syntax this wiki engine uses and get even more motivated by it so that our children don t have to suffer the same RadomirDopieralski 2006 01 06 The link syntax particularly relative order of text and link is one of the biggest issues needing to be resolved for reconciliation with the Crossmark draft spec My current recommendation is that we follow the PmWiki usage which is also similar to PukiWiki and Netcipia except for choice of delimiter Specifically the favored link syntax should be text of link link For compatibility with the majority of Wiki usage especially MediaWiki we can also support link text of link Minimalist or purist subsets of Creole can omit this alternate syntax Chuck Smith above has indicated a preference for this alternate syntax so it would give him extra user freedom too at the expense of slightly more parser complexity and the potential confusion of readers seeing both syntaxes Ivan the first author of Crossmark feels strongly that putting the text first is more natural and that the link first syntax is an artifact of a poorly thought out wiki implementation The current Crossmark draft follows the JSPWiki convention and as discussed extensively above it s very confusing especially people used to other wikis Ivan has expressed a definite willingness to change the syntax and has been considering the PmWiki style anyway Because it s used by PmWiki it s NotNew I believe it also satisfies the goals of ReadableMarkup and EasyToLearn because has the intuitive meaning of go to visually resembles the presentation of external links on many wikis and telegraphs which way is which something that has been poisoned for pipe given that there seems to be a 1 3 2 3 split among wiki engines Raph Levien 2007 01 11 For the record I said above that I wanted the link to be first and then the description Anyway if others like it I could be convinced that using is a very clean and intuitive link syntax I m curious to hear opinions of other Creole participants ChuckSmith 2007 Jan 12 I feel strongly that putting the title first and link second is more natural and far more readable than link first title second which is pretty much an artifact of how HTML works However whether the delimiter is or does not matter to me much The latter is clearer though considerably slower to type since it seems to in practice require spaces around itself Janne Jalkanen 2007 Jan 14 Just a loose suggestion if we are going to use an additional link markup why don t we tacle the InternationalizationConcerns phew now I know why they type i18n Another option would be to not define the markup for links with different link text for internal pages in external links the order can be detected But that s rather dodging the problem and it would cause problems when actually using it Another possibility only have special markup for the link text But in general this is a very broad topic How should we tackle it Should we at all RadomirDopieralski 2007 01 15 I changed a little the advantages and disadvantages still fail to see How one of the markup is intuitive and the other is not What does intuitive mean at all How the markup is better for international keyboards How the order of link description is obvious I initially thought it s link description How does it work with right to left scripts By the way as I see it the problem is only with the internal links with different link text the address in an external link can be easily detected and there is no description in simple internal links http some external link http some external link external link external link http some external link some internal link some internal link internal link here is the problem On solution that is keyboard friendly and conflict less is http some external link http some external link external link external link http some external link some internal link internal link some internal link some internal link internal link but I think it s too exotic RadomirDopieralski 2007 01 16 On the main page for this proposal Chuck Smith lists really confusing on right to left languages like Hebrew I d like to hear from real Hebrew or Arabic speakers with Wiki experience my codeveloper on Ghestalt is Israeli so I can ask him but as far as I can tell this assertion is simply wrong Here s what both link styles look like in your browser אירופה היא אוסף של חצי אי חצאי איים מחוברים אירופה היא אוסף של חצאי איים חצי אי מחוברים And the result should look something like this אירופה היא אוסף של חצאי איים מחוברים In both cases the text to be rendered is two 4 character words and the target is a three character and a two character word If anything the arrow is considerably less confusing because it always points at the link RaphLevien 2006 01 16 And then they want to link to an English language resource maybe also with a Hebrew description which way should the arrow point then But yes I d also like to hear from someone from Israel I would be against allowing arrows in both directions because I think that would just add to the confusion ChuckSmith 2006 Jan 17 Reversing should lead to which is very confusing MicheleTomaiuolo 2007 01 17 We really really need someone with Bidi experience to enlighten us But the arrow is reversed in presentation The string is and I did not change my link regex in any way to accommodate rtl languages Bidi is inherently confusing and this arrow reversal was new to me but the goal here is not to add to existing confusion The examples above were all Hebrew but I did some poking around into links with a URL target which of course needs to be a LTR span because it s in ASCII Basically as long as the primary direction is marked as rtl this is an attribute of the top level html tag and can be overridden through an inheritance mechanism it looks pretty good The arrow points to the left and the URL appears to the left of it exactly as in the all Hebrew example If the direction in the HTML is left as LTR as is the case on this wiki then the all Hebrew links are still fine but the mixed direction ones are a total hash This is definitely true for both alternates and imho the hash is equally undecipherable in both cases But again I think this is an issue for HTML based Bidi applications in general and not something that s within our scope to try to fix I did note that both Mac TextEdit and Carbon Emacs did a much better job in these cases presumably because they use a heuristic to determine the text direction rather than relying on HTML markup Thus messing with this stuff in an editor is a viable option I also observed that ASCII link targets within sentences are exceedingly rare Link targets within sentences are overwhelmingly Hebrew and when ASCII link targets occur they seem to stand alone for example as a bullet item I do not know if this tendency is influenced by Bidi glitches or is a matter of style but in either case it would seem to keep the incidence of hideously confusing Bidi mixing to a minimum Therefore my assertion that the arrow is less confusing stands People who want to experiment with the proposed link syntax are welcome to use the Ghestalt sandbox You ll have to create an account to get edit permissions otherwise I fear the site would be overrun by spam but Creotians are more than welcome RaphLevien 2007 01 17 What is bidi Wikipedia says it s an indian cigarette ChuckSmith 2007 Jan 18 Bi directional text like a hebrew text with latin fragments RadomirDopieralksi 2007 01 018 I would like to use sometimes in link descriptions What about allowing those three alternatives adding double angle brackets Rule is imple The desription is always on the larger side the url always on the smaller side or in other words where the arrows points to http www wikicreole org a common wiki markup thats what we have already a common wiki markup http www wikicreole org for the left to right languages http www wikicreole org a common wiki markup for the right to left languages this would allow me to express something like this see file print http www somedocu com wiki printmenu ChristophSauer 2007 01 24 I implemented choosing the rightmost right arrow as the delimiter in the case of more than one This prohibits right arrows in links but URL s can be hex escaped and the right angle bracket is certainly not common There is a little more discussion of similar corner cases in Crossmark Creole Unification and Talk PatrickMichaud contains Patrick s positive experience with the arrow syntax And let me reiterate the left pointing arrow in the example above is the ASCII string not It s confusing I know but the confusing part is Bidi text layout rules not Wiki syntax Raph Levien 2007 01 23 The following ASCII characters are not allowed in HTTP addresses space whenever they appear in an url they must be encoded The RFC 1738 also suggests a way of representing urls in various contexts see appendix at the end In addition there are many occasions when URLs are included in other kinds of text examples include electronic mail USENET news messages or printed on paper In such cases it is convenient to have a separate syntactic wrapper that delimits the URL and separates it from the rest of the text and in particular from punctuation marks that might be mistaken for part of the URL For this purpose is recommended that angle brackets and along with the prefix URL be used to delimit the boundaries of the URL This wrapper does not form part of the URL and should not be used in contexts in which delimiters are already specified I shall also note that there is absolutely no problem with the current syntax and urls the link description order can be easily detected The only problem is with internal links with descriptions RadomirDopieralski 2007 01 24 I would keep this discussion for optional extensions In fact my impression is that the current syntax is good enough for core specification As Radomir said no problem with urls Conflicts can be solved Engines can detect the right order and easily support the Creole way if they expect url text in the reversed order Probably we could also leave the syntax for alternate text with internal pages unspecified in core to solve existing conflicts I guess it s not used very often and it won t be a great problem if Creole doesn t standardize it Just an impression we should check Instead requiring languages to support both ways won t help solving the confusion It would leave existing conflicts unsolved and it would add new ones Otherwise yet another syntax the arrow As an extension it would have some sense I m not for it anyway MicheleTomaiuolo 2007 02 06 I m tempted to agree with just leaving the local links with descriptions unspecified they are indeed very rarely needed on real wiki sites written in languages like English or even Chinese There are two problems Sites that use wiki engines under the hood but are not really wikis just some kind of simplified CMS es This is not a big problem as they woudn t benefit from Creole much anyways no content exchange and very few new users Wiki sites in languages that do complicated things with words like Polish It s practically impossible to use page titles in sentences unmodified everywhere and such sentences sound very unnatural Suppose you have a WikiPage page StronaWiki and you want to write a sentence like You can find useful information on WikiPage In Polish it would be Możesz znaleźć użyteczną informację na Stron ie Wiki Links with descriptions are the only sane solution I shall note that the Polish Wikipedia is among the top biggest Wikipedias on the list On the other hand additional link markup seems to be a burden for core Creole something that seems suited for the additional markup I really can t see the right solution here all of them have their advantages and disadvantages and none dominates RadomirDopieralski 2007 02 06 Wait a minute Where did the link description proposal come from Did somebody misread the right to left language discussion above perhaps mistakenly believing that the string

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

  • Talk.Axel Rauschmayer
    SA Sponsored by the Wiki Symposium and the Nuveon GmbH view find Quick search type ahead Recent Searches Clear Talk Axel Rauschmayer Your trail Talk Aims Home Talk AlainDesilets Home Talk AlexSchroeder Home Talk AllMarkup Home Talk AlternateLinkSyntaxProposal Home View Page Discussion V iew A ttach I nfo Hello Axel welcome to the Creole wiki I can see you have large experience with developing machine languages in general and wiki

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

  • Talk.Bayle Shanks
    C by the contributors Some rights reserved license BY SA Sponsored by the Wiki Symposium and the Nuveon GmbH view find Quick search type ahead Recent Searches Clear Talk Bayle Shanks Your trail Talk AlainDesilets Home Talk AlexSchroeder Home Talk AllMarkup Home Talk AlternateLinkSyntaxProposal Home Talk AxelRauschmayer Home View Page Discussion V iew A ttach I nfo Welcome Bayle thank you for your support we need it very much it

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



  •