| At line 298 added 182 lines |
|
| What is bidi? [[http://en.wikipedia.org/wiki/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|http://www.faqs.org/rfcs/rfc1738.html] 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 [[http://pl.wikipedia.org|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 {{{<-}}} is required to make the left-pointing arrow in such languages? No, the string {{{->}}} means that the link follows the description in the natural flow of the language, whether LTR or RTL. There is broad consensus (but not unanimity) that this flow reads more naturally than "link then description." |
|
| I recommend that the {{{<-}}} proposal be retracted. I'm still in favor of {{{->}}} though. |
|
| -- [[Raph Levien]], 2007-02-06 |
|
| Didn't we just agree that the best order of link/discussion is dependent on the use cases and user habits and cannot be chosen once and for all? |
|
| If the goal of this proposal is to just replace the syntax used by 90% of wikis with the syntax used by 10% of them and found by their users "more intuitive", then I think the whole thing should be rejected. |
|
| -- RadomirDopieralski, 2007-02-06 |
|
| I'm suggesting we keep the pipe syntax (compatible with majority of wikis, especially MediaWiki) for those users who prefer the link-first order. I'm just saying that I don't think we should have both pipe and left-arrow. |
|
| -- [[Raph Levien]] 2007-02-06 |
|
| If I understood correctly, Creole is not going to abandon the pipe syntax. So arrow-style links won't add any functionality to the language, even if they're visually more "appealing" and understandable. |
|
| Requiring wikis to support another link style means making Creole acceptance a bit harder, while not making it more expressive. Shouldn't it be an extension? |
|
| What's the role of extensions, btw? Making Creole itself a complete language is a goal, ok. But they could also serve as suggestions for other wikis. Shouldn't them be formalized in versions etc? They could be added to core afterwards, if they become widespread enough. |
|
| -- [[Michele Tomaiuolo]], 2007-02-10 |
|
| How about the detection of external links and choosing the order automatically based on it? |
| * If there are no external links on either side of pipe, use the default link/description syntax. |
| * If there is an external link on either side, use it as the link the the other side as description. Strip leading and following spaces, convert the spaces inside the link into %20. |
| * If both sides are an external link, don't render it as link at all -- somoene tries to cheat on the users. |
|
| I'm aware that this takes away some user freedom -- linking to one url while displaying other and linking to pages with names being urls. But I think that both cases should be avoided anyways. |
|
| -- RadomirDopieralski, 2007-02-10 |
|
| Michele: the main motivation for me proposing the right arrow syntax was compatibilty with a proposed change in [[Crossmark]]. At this point, I don't know if they will be adopting that change or not. I don't see much activity from the Crossmark maintainers, and the discussion of [[Crossmark Creole Unification]] seems entirely stalled. Ivan, the main author of Crossmark, feels quite strongly that the description-first order reads more naturally, and that he should not be bound by the precedent of existing wikis if the original choice was an accidental mistake. |
|
| Adding to his argument is the fact that not //all// wikis implement the description-first order in pipe syntax. So, if you see {{{[[alpha|beta]]}}} out of context, there's still considerable ambiguity of which is which. Further, the arrow syntax can be implemented as an extension by all wikis without having to change their pipe syntax. Thus, if we encourage the use of the arrow as "best practice", then links can port reliably to all such wikis. |
|
| Of course, these arguments depend quite a bit on what Crossmark actually adopts, and to what extent other wikis adopt parts or all of the Creole standard. But I think there's a very good chance it will turn out to be a great help, and even if not, the cost is low - at least we get to write links in a syntax many people feel is more natural. |
|
| Radomir, your reasoning on external links seems sound to me. The consistency-favoring part of me is screaming, "hey, if {{{[[description|http://example.com]]}}} works, then why not {{{[[description|target]]}}}", but your proposal seems likely to do the right thing for users most of the time. I've had the experience many times of seeing a blue underlined url linking to a bare word in preview, and under your scheme that would simply go away. |
|
| -- [[Raph Levien]] 2007-02-10 |
|
| I dislike the [[foo -> bar]] and [[bar <- foo]] proposal. As far as I am concerned, we're trying to make a small common set of rules. These two don't belong. |
|
| -- AlexSchroeder |
|
| I don't particulary like this either. Seems to assume there are only two parameters to a url link, so makes extensibility harder, if for instance what to add a title too. |
|
| Would much rather a method that say prefixed the local wiki page name with a character (/ maybe?). |
| So any amount of arguments could be used. Along the lines of CSS composite rules. |
| Eg. |
| {{{ background: #fff url(Foo.gif) 50% 3px no-repeat }}} |
|
| All the values distinct, so can be in any order. |
|
| -- [[JaredWilliams]], 2007-02-13 |
|
| Also whatever method is decided should be applied to images {{{ {{ }} }}} too, for consistency. |
|
| -- [[JaredWilliams]], 2007-02-13 |
|
| Aren't we trying to be too creative here? There is already one good and generally accepted way of making links. It works, it is generally widespread, and I think we should be pretty happy about it. Ok, someone pointed out the problem with having to paste or read long urls before finishing a thought and reading the link text. We can solve that by detecting the url/description order (Although I think that this would be ideally normalized, for example by some preprocessor, before saving. Of course no such thing in Creole). |
|
| Now we have a totally new markup introduced that does nothing new. The only purpose is to make some experienced users of certain wiki engines happy. I say that experienced wiki users are pretty familiar with the idea of wiki syntax and can adapt easily -- let's not carry over this division to the new generation of wikizens. |
|
| I have also a **huge** problem with this proposal. There are 3 advantages listed for this newly introduced markup: |
|
| * **There exists one wiki engine that uses it.** How is that an advantage? There exist hundreds of wiki engines that don't use it. |
| * **Works better with international keyboards.** How does it work better? Sorry, but I fail to see it. Can someone demonstrate it? |
| * **The order of link and secription is indicated in the markup.** I don't see it how it's obvious that the arrow should point from the description to the link and not the other way around. This had to be learned too. And this is no different than just learning what comes first, because the variant with the arrow pointing in the opposite direction is frowned upon. |
|
| Honestly, I can't see how a proposal with such poor argumentation got into Creole 0.5. |
|
| -- RadomirDopieralski, 2007-02-14 |
|
| Can we narrow the proposal to a single concrete syntax now, and list the advantages properly, possibly taken from this discussion? |
|
| Personally I'd see this as a Creole addition, to be used where there is demand for this kind of feature. But that's just me. |
|
| -- RadomirDopieralski, 2007-02-14 |
|
|
| That's ok for me, but don't call all of this poor argumentation - it's unfair and I disagree. I don't necessarily want to have it in a Creole 1.0, but defenetely I would like to see something like this as a implementation addition (or //addition reccomendation//) now, and in the core in later versions. |
|
| -- ChristophSauer, 2007-02-14 |
|
| I'm sorry, I was hoping to provoke refactoring ;) |
| But you are right, this is not poor argumentation, just the real arguments that are present in this discussion are not summarized on the proposal page. Please accept my apologies for the aggressive behavior. |
|
| -- RadomirDopieralski, 2007-02-14 |
|
| I really thought you where serious. apologies accepted :) |
|
| -- ChristophSauer, 2007-02-15. |
|
| Since some people complain about their difficulties in entering square brackets for links, why not to change this extension to use parenthesis? |
|
| I'm not convinced Creole needs an alternative syntax for links... but it would make life a bit easier for someone. |
|
| ((a link to -> another page)) |
|
| -- [[Michele Tomaiuolo]], 2007-03-01 |
.