* Tim Starling wrote: Great! Wonderful job Tim! This is wonderful and will vastly simplify tons of things. I need to get busy converting all the 'date math' templates to use 'expr:'. And phasing out the 'calcadd' and 'calcsubtract' templates. And building out conditional row functionality for all the infoboxes with '#if:'. And converting Wikipedia:Featured content to use 'rand:'. And... oi! Damn you Tim! :]

* William Allen Simpson wrote: I suggested on 'Village Pump (technical)' that we apply changes to high traffic pages first and see how it plays out. Provides a reasonable stress test, but fewer pages to revert if there are problems. That's about the extent of 'coordination' this far. The m:ParserFunctions talk page would probably be a good spot for further discussion.

Gerard Meijssen wrote: From my experience with Gangleri's bug reports, I can safely say that what this means is "it's hard to read the markup in a web browser's text editor, particularly in Firefox, so sometimes people get confused and type things in the wrong order when editing". Unfortunately mixing markup characters, a right-to-left environment, and left-to-right numbers and keywords often does lead to an illegible mess in the basic text editor widgets that you'll find in a web browser. Please note that: 1) Localized (thus right-to-left) keywords can be provided if necessary. 2) Numbers are left-to-right even in the right-to-left scripts. *You thus cannot avoid mixed-directionality text when doing "math" stuff.* and most importantly: 3) This is no different from the case of templates, whose syntax and markup usage is nearly *identical* to this extension. The argument given here thus fails on its face, as it would apply equally against the use of existing templates. -- brion vibber (brion @ pobox.com)

As I understand it, we simply need someone to keep the LanguageAr.php file up to date to localize the relevant keywords. When MediaWiki provides the _functionality_ to localize something, but it is not localized because a volunteer hasn't done it, it isn't MediaWiki that is broken. We just need people to maintain the language files in each language; whether it's LTR or RTL is irrelevant. This process can of course be expedited by paying someone to do it. As for distinguishing between minor annoyances and things which are "horribly broken", I'd like to see some surveys among the actual users of the various non-English Wikipedias. As things are, I am entirely unconvinced that it is RTL issues which are the cause of the fact that ar.wikipedia.org has "only" 12000 articles. Limited access to or use of the WWW would be a much more important factor. Erik

I have made two (one) example implementation on the english wikipedia that I think might be useful, it's http://en.wikipedia.org/wiki/Template:Leap_yearand http://en.wikipedia.org/wiki/Template:Tomorrow2 (tomorrow was already taken)

Gerard Meijssen wrote: In other words: the argument *does* fall on its face, but we can make a totally different argument: that it would be nice to support RTL better. Yes, it would be nice to support RTL better. However that has nothing to do with banning a construct that has THE EXACT SAME ISSUES AS THE TEMPLATES IT WOULD REPLACE. -- brion vibber (brion @ pobox.com)

On Thu, 13 Apr 2006 12:29:58 -0700 Brion Vibber <brion(a)pobox.com> wrote: Thanks Brion for this constructive approach. There are many places to start, many issues have been reported and many test have been made but I see no "road map". One of the bidirectional issues all projects could benefit from is to implement "fix location lists" for the special pages. Onece you did it one time it is trivial. See the three pages sharing identical source code: http://epov.org/wd-gemet/index.php/Wikidata_M2:Special_pages/%21list#specia… http://www.anubite.co.uk/mediawiki/head-rtl/index.php/Mw16:Special_pages/%2… http://www.anubite.co.uk/wikis/test-fpr/index.php/Farsitest:Special_pages/%… In these lists the position of relevant fields are preserved *regardles* of the directionality of the content. This is exactly what users would expect from special pages. There are two more open requirements which can RTL / BiDi live easier: Facilitate bidirectional editing / readability via a trailing escape character (as "\") at the end of line http://bugzilla.wikimedia.org/show_bug.cgi?id=05121 It would be fair to allow multiline syntax in MediaWiki same as all the MediaWiki software is written. Magic words (pedefined templates) {{UTF-8DECODE:}} {{UTF-8ENCODE:}} (optional {{UTF-8ENCODE8:}} {{UTF-8ENCODE16:}}) http://bugzilla.wikimedia.org/show_bug.cgi?id=5256 This is not a constructed request. The feature can save hours. Regarding my objections against not supporting table code in the conditional templates please respect that I tell / write what I think and that I write it now. The minimal compromise which would not harm template syntax nor conditional templates would be be the support / processing of the "trailer" in conditional templates. This is not banning as mentioned in your email: best regards reinhardt [[user:gangleri]]

On Thu, Apr 13, 2006 at 10:09:48PM +0200, Gerard Meijssen wrote: You know what's weird? I agree with Gerard, kinda. If there's a structural problem with the API to a template implementation of functionality, then the time when you reimplement that API into the core is the time to fix it, if you can, if only to avoid institutionalizing an API with a structure which can't be extended in the necessary fashion. I don't know that this is that case, but if that particular aspect of the thing hasn't been examined, perhaps it should be...? Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on Usenet and in e-mail?

Reinhardt WIEWE @ torg.is wrote: Yes, I can see that it's a mess. But what would you propose instead? Would it be easier to edit if it was _all_ in Hebrew, with no Latin letters at all? As far as I know, this should be possible: all the MediaWiki keywords can be localized, and template names and parameters can of course be changed on each wiki. The only major problem I see are HTML tags -- I don't think MediaWiki has any way to localize those. -- Ilmari Karonen

Reinhardt WIEWE @ torg.is wrote: You can already have line breaks here, can't you? -- brion vibber (brion @ pobox.com)

I'm a recent addition to this list. I joined after the Apr 9 outage, thinking that as a longtime Internet engineer I'd be able to help on operational issues. Sadly, that doesn't seem to be a focus here. Never-the-less, these parser functions have been requested for a long time and been a source of considerable acrimony. I'm very happy they have been implemented, and as the trial proceeds, it's possible that improvements will be made. However, the RTL issue doesn't seem to have anything to do with these functions in particular. It may be an issue with parsing all templates. We covered these issues in great detail in the IETF over a decade ago. There was a lot of acrimonious argument then, too, but Hank (and others) did a great job drafting a technical solution that solved the transmission and editing problems. (1) A canonical form for storage and transmission. In SMTP, all storage and transmission is LTR. I don't see why that couldn't apply here, too. Sure, it makes Hebrew appear backward in storage, but we usually don't look at the stored version. (2) Display and edit as RTL. In practice, this turned out to be fairly simple by thinking about such things as opening and closing parentheses, rather than left and right. They simply are reversed on display. (3) This allows all email to be parsed consistently, without change to the existing mail transmission programs, while specialized mail user agents (MUA) handle display of the text body. In this case, I don't see why the templates cannot be parsed in the standard canonical order, but displayed RTL as an option. Then, there's no need for line continuation escaping and such ugliness, that would just interfere with RTL editing. Just reverse the template syntax on display, along with everything else; * without localization (BiDi): {{else|then|test:if#}} * assuming localization of the words: {{esle|neht|tset:fi#}} That would seem to correlate with my memory of the recommendations of W3C, too, but I'm no expert there.

On Thu, Apr 13, 2006 at 09:11:28PM -0400, William Allen Simpson wrote: Note that there are many lists related to MediaWiki and Wikimedia Foundation issues; it's possible that you're on the wrong one. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on Usenet and in e-mail?

Moin, On Friday 14 April 2006 05:51, Tim Starling wrote: There really is nothing you can do it people absolutely, positively want to re-invent the wheel aka: a new programming language in completely new environment. I have said my reasons against it, and that's it. Best wishes, Tels -- Signed on Fri Apr 14 11:14:30 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "I know what I don't know, and to this day I don't know technology and I don't know accounting and finance." -- Bernie Ebbers, former WorldCom Inc. CEO, speaking in his defense during the WorldCom fraud trial.

On Fri, 14 Apr 2006 13:51:58 +1000 Tim Starling &lt;t.starling(a)physics.unimelb.edu.au&gt; wrote: Thank you Tim for your work and for working on extending the template syntax which was pending for a while. Sorry if some of my comments have been 'sarcastic' but I never tried to be polemic. Thanks for the trimming and supporting new lines between the delimitors. My comments where mainly based on the "missing somthing" in the syntax, on the interaction with other features. As has been suggested at http://meta.wikimedia.org/wiki/Talk:ParserFunctions there are 'solutions' to implement different needs (as table support) but these are 'workarounds' falling back to HTML syntax usage, escaping tricks and various usage of expoits (because of the knowledge how the implementation is today). I suppose that the "missing somthing" is a "grouping construct" and the syntax can be realy simplistic: {{# <wikisyntax> }} where <wikisyntax> is whatever valid wikisyntax as (sub)table code etc. The idea comes from http://meta.wikimedia.org/wiki/Talk:ParserFunctions#.23switch where {{#switch: VALUE-TO-BE-TESTED | foo|bar = hello | baz = world | = Neither ''foo'' nor ''bar'' nor even ''baz'' }} could also be {{#switch: VALUE-TO-BE-TESTED | foo|bar|bla|more = hello | baz = {{# world }} | = Neither ''foo'' nor ''bar'' nor ''bla'' nor ''more'' nor even ''baz'' }} regarding {{#if: 1 || literal pipe: | }} I suggest that if you could implement {{# <wikisyntax> }} then the best way would be to output FAST and LOUD an 'Invalid trailer' error message. This defetes arguments that the syntax is not symmetrical with respect to the <then> and <else> branches. {{# }} will be / should be stable agains {{subst:}} (and the {{substall:}} feature request). best regards reinhardt [[user:gangleri]]

Brion Vibber wrote: Yes, that's good, a canonical form for storage. But not when editing. The edits are handled by specific MUA. Some expose the raw markup, others hide the markup and handle the conversions. I'm sorry, perhaps I'm not sufficiently clear. The final output of text pages should always be handled in the standard canonical manner. It's the edits that seem to be the problem. The edit box is defined and filled and processed by Wiki software. That is, this software is providing the UI. So, I was proposing that the Wiki software do the flipping into the edit box, then reversing and preprocessing from the edit box back into the canonical format. That is, folks seem to have a problem with treating the edit box the same as a raw text editor. I was using the parallel that user freindly email editors don't treat the text as "raw", instead they handle the user edit processing and conversion from/to the canonical format. Likewise, the difference in editing pages with Mozilla as opposed to the raw HTML with BareBone's BBEdit (my personal preference). Most folks seem to like the former. Still clear as mud?

Jay R. Ashworth wrote: Say Jay, you're as acerbic as ever. Anything's possible. Any suggestions?

Ilmari Karonen wrote: Aha, I'd not considered that this problem would also occur with the HTML markup itself. Seems like the same problem as templates. I only knew about "<BDO>...</BDO>" but not "bidi-override;" for entire sections, very clever. Might check with a variety of editors in several languages, as Gangleri admits he doesn't actually write them. Are these well represented on technical lists?

On Fri, Apr 14, 2006 at 11:14:21AM -0400, William Allen Simpson wrote: You're projecting, William; that was as even-handed as anything I ever say. On looking at the mailing list descriptions at http://mail.wikimedia.org/ though, I'd have to say I'm wrong; this apparently *is* the ops list. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on Usenet and in e-mail?

On Fri, 14 Apr 2006 11:53:17 -0400 William Allen Simpson &lt;william.allen.simpson(a)gmail.com&gt; wrote: I would not use 'bidi-override' for my personal work. Remember it is a matter of preferences and available options. I made aprox. 10,000 RTL edits in the normal textarea box and get used to it. The main question is if it would help *other* contributors. This depends on the available options and some might like 'bidi-override'. If people are using a RTL browser, a RTL OS (or a RTL keyboard) if they have an RTL editor of their choice they would have completly different preferences. Please remember that MediaWiki supports the usage of an external editor via special:Preferences > Editing > Use external editor by default . I neither have used an external editor for LTR edits nor have I investigated about experiences with an external editor with good RTL / BiDi support. I will let you know as soon as I get additional informations. http://yi.wiktionary.org/w/index.php?title=user:Nikerabbit/monobook.css&… "Making everithing ltr" is the default setting for http://ar.wikipedia.org/ and http://he.wikipedia.org/ for logged in users. Anonymuous users would still have an RTL textarea. I mentioned this in a previous post. It is an option; my opinion about this: as more option you have the more flexible the system will be. The fair answer is: It is the *last choice*. If I need to debug a template or page I copy the content and past it to http://pastebin.com/ . This is equivalent to 'bidi-override' when direction is 'ltr'. pastebin.com offers the additional advantage that I am able to identify (unwanted) general punctuation characters which have found their way into the code by eroneous copy and paste. Why 'bidi-override' when direction is 'rtl' should not be a good solution for someone comming from / native in the RTL world? Please note that RTL and mainly BiDi source code *editing* is very complex, that the bidirectional algorithm works on / resets on entities as paragraphs, table cells etc. And please do not forget that the nesting levels are limited. What the textarea box editing is is mainly writing an email in Outlook / Outlook express in *source code*. Nobody would do that. And things are changing slowly so it is very important to know the texarea editing capabilities of the browsers (and Firefox is a very common browser). As more lines you have in the textarea as less bidirectional "mess" you get. You would still need to get used to the bidirectional algorithm but the effects are limited to *one* line only. This is where the suggestion of splitting the template (and page) code over many lines comes from. reinhardt [[user:gangleri]]

"Reinhardt WIEWE @ torg.is" &lt;gangleri(a)torg.is&gt; escribió en el mensaje news:web-153858978@heimsnet.is... (....) At http://bugzilla.wikimedia.org/show_bug.cgi?id=4011 there is a a javascript workaround by Zigger, http://meta.wikimedia.org/wiki/User:Zigger/Bookmarklets and it seems to work fine. Why is it not in the common monobook.js? I know it woill only work on javascript browsers or even only on those who support our toolbar but it seems would be a GREAT improvement, and any easy change would use javascript... Platonides

Locke Cole wrote: I've never found adding a space before the colon at the end of a sentence fragment to be easier to read, either. What's hard to read about "#if:"? "#ifeq:"? "#ifexpr:"? Spaces are allowed after the colon, correct? The documentation just changed today, so it's a done deal. Note that even the documentation says: ... It is intended as an "if defined" structure. ... So, it should be called "#ifdef:" to match ingrained expectations. Could "#if:" be quickly retired? Also, "#ifexpr:" just showed up in the documentation today, so you'll forgive me for not knowing about it. And wouldn't we just use "#ifexpr: X = 0" otherwise? "#ifeq:" is for matching strings, not against "0". See what I mean about ingrained expectations?

Steve Bennett wrote: As I always say, there's a difference between inventing the wheel and making a wheel. There was no expression parsing module available written in pure PHP. There were clear advantages to having one, so I wrote it, and it only took a few hours of work. I based my work on an algorithm invented in 1960 by Edsger Dijkstra. The same applies for other MediaWiki syntax features. Old ideas in a new form. -- Tim Starling

On 4/14/06, William Allen Simpson &lt;william.allen.simpson(a)gmail.com&gt; wrote: It's not just literal spaces, but *any* whitespace (carriage returns, tabs, etc). So you could do, for example: {{#if :<string> |<then result> |<else result> }} Note also that the result strings are also trimmed of whitespace, so the CR/LF are ignored. #if is shorter which is probably why it'll be kept as-is. I proposed it on the talk page a little while ago (which is where most discussion is going on right now). Yes, you could use #ifexpr as you describe I suppose. =) I was mostly thinking of situations where a template would return 1 or 0 for true or false (see [[en:Template:IsLeapYear]]). Everything is a string. You could use #ifeq or #ifexpr (though I suspect #ifeq would be faster as far as CPU resources are concerned). -L

Locke Cole wrote: Any number of strange examples could be proposed, but I'd expect that parsing the token is easier with the colon attached. I'll leave that to the expert implementors. I just want to put my oar in saying it's really a waste of effort. Oh, and I'd just write that as (I hate it when folks move the test away from the conditional): {{#if: <string> | <then result> | <else result> }} Yeah, saw that in the code. Here's where I jump up and down and holler! Short is *NOT* an important desired design constraint! Speaking as somebody with a fair amount design, documentation, implementation, and operational experience (you all use my work every day), it's really important to keep things as consistent as possible. Remember the principle of least surprise! Folks are likely to do things based on prior experience. Folks writing templates are even more likely than the general editors to have programming language experience. Consistency may be the hobgoblin of little minds, but there are a lot of small minds to worry about -- it's not foolish! The semantics of "#if:" no longer match the semantics of PHP if. The semantics also do not match the semantics of CPP #if, but the visual representation will bring that to programmers' minds. This is closer to CPP #ifdef. If not changed to "#ifdef", I foresee eons of queries and errors. Now is the time to rectify the situation. There are only a few instances, and it should be easy to add #ifdef: and remove #if: a few days later. With the holiday activities, there should be less going on right now, so this is an excellent time to work on such changes in the background with less stress on the servers. I tried to join meta some time ago, but it wouldn't let me login or create my name. I checked the logs, and there are no others with my name. There is/was some form of restriction of participants? I'm hoping that single sign-on will handle everything soon.

On Fri, 14 Apr 2006 17:39:25 -0700 Brion Vibber &lt;brion(a)pobox.com&gt; wrote: Thanks a lot Brion! If you know how to use it it can be very practical because it has different modes. At http://test.leuksman.com/index.php?title=%D7%A2%D7%A8%D7%A9%D7%98%D7%A2_%D7… you can see that I found a half a dozen of syntax errors and more cosmetic issues. It seems to be very practical to have the *option* to disable tidy (which is not activated on many wikies outside the WMF). This is starting from a copy of the Main Page fo Yiddish Wikipedia http://yi.wikipedia.org/ Of cause the Monobook skin of FiverAlpha is LTR and not RTL. I also added 'direction: rtl;' to the table cells and changed font-size and font-family to a more traditional one known from printed books. I can keeping testing also on the copy of the Hebrew Wikipedia main page source. dankegon! best regards reinhardt [[user:gangleri]]

Stephen Bain wrote: Actually, wikisyntax is a language by definition. Looks LALR(1). I've always assumed there was solid computer science going on here, rather than mere ad hoc jiggery pokery. You can't "make" people do anything, let alone "stop and think". Always better to plan for implementation and operational consequences in the design process. Surely, I'm preaching to the choir.... Moreover, why are you denigrating "just" wikisyntax?

Well, I don't see the need of "bidi=normal" and "bidi=override" - it will confuse everyone a lot, and not really needed. If someone has a problem, he just switches to LTR text-box. There are (built-in) shortcut keys: Ctrl+LeftShift in Internet Explorer (in almost every Windows program), Ctrl+Shift+X in Mozilla, Firefox, Netscape, etc. (when bidi.browser.ui is working, or when the system locale is a RTL language - it was automatically enabled in Windows XP I've installed, by unluckily not in Manriva Linux; however, most of the people use Windows XP, and it is automatically enabled for them in Firefox; and most of them use Internet Explorer, which has no problem at all with Ctrl+LeftShift), but a button may help. Maybe additional button in the toolbar for switching the text direction. By the way, Firefox has additional problems, because it preserves the direction of the text even after a line-break; however, it's a known problem, and Firefox users know it - and most of the world uses Internet Explorer. Additionally, the most problems are fixed when switching to LTR. You may say that some of the users don't know they can switch to LTR - but who will deal with the problems? The more technical users, which edit templates, and know some things about the computers. Including that info about Ctrl+LeftShift and Ctrl+Shift+X. I don't think there is a need to add buttons, but if you want, you can add a button to the toolbar - nothing more. (I'm not sure it's technically possible, but maybe there is a way that a button in the toolbar won't use addButton.) rotemliss, a writer in all the Hebrew projects, excluding Wikinews Brion Vibber wrote:

On Sat, Apr 15, 2006 at 09:07:09AM +1000, Tim Starling wrote: Well, as long as you're stealing your ideas from the right people, then it's not ad-hoc, or jiggery pokery. PS: your mailer wraps at about 90 characters... Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on Usenet and in e-mail?