The extension for mathematical expressions and conditional constructs has been enabled on all Wikimedia wikis, on a trial basis. Documentation is at:
http://meta.wikimedia.org/wiki/ParserFunctions
See the talk page for discussion.
-- Tim Starling
* Tim Starling wrote:
The extension for mathematical expressions and conditional constructs has been enabled on all Wikimedia wikis, on a trial basis. Documentation is at:
http://meta.wikimedia.org/wiki/ParserFunctions
See the talk page for discussion.
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! :]
Conrad Dunkerson wrote:
- Tim Starling wrote:
The extension for mathematical expressions and conditional constructs has been enabled on all Wikimedia wikis, on a trial basis. Documentation is at:
http://meta.wikimedia.org/wiki/ParserFunctions
See the talk page for discussion.
Great! Wonderful job Tim! This is wonderful and will vastly simplify tons of things.
When Tim says "trial", how is the testing coordinated? Shouldn't it be tried on a few not too prominent places, rather than fix every qif now?
Where should I be looking for posts coordinating this?
* William Allen Simpson wrote:
When Tim says "trial", how is the testing coordinated? Shouldn't it be tried on a few not too prominent places, rather than fix every qif now?
Where should I be looking for posts coordinating this?
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.
William Allen Simpson wrote:
Conrad Dunkerson wrote:
- Tim Starling wrote:
The extension for mathematical expressions and conditional constructs has been enabled on all Wikimedia wikis, on a trial basis. Documentation is at:
http://meta.wikimedia.org/wiki/ParserFunctions
See the talk page for discussion.
Great! Wonderful job Tim! This is wonderful and will vastly simplify tons of things.
When Tim says "trial", how is the testing coordinated? Shouldn't it be tried on a few not too prominent places, rather than fix every qif now?
Where should I be looking for posts coordinating this?
The main reason I'm calling it a trial is to avoid appearing to have made a unilateral decision to enable it permanently. The critics of this concept now have one final chance to turn community opinion against it, before it becomes ingrained. However the reception has generally been positive. I've received a number of private compliments on it, in addition to what can be seen publically.
There's also the possibility of bugs and syntax changes. We've already had one syntax change: I changed the whitespace handling in #if to mirror the behaviour in template parameters, to allow for easier conversion and neater multi-line syntax. There's also a pending suggestion to allow whitespace between the #if and the colon, and a suggestion to make #if treat "0" as true, both of which may well be implemented.
One of Gangleri's syntax suggestions sounded quite reasonable and I may well implement it. The idea if I understand it correctly was to treat pipe characters beyond the specified maximum number of arguments literally, e.g. {{#if: 1 || literal pipe: | }}.
-- Tim Starling
Moin,
On Friday 14 April 2006 05:51, Tim Starling wrote:
William Allen Simpson wrote:
Conrad Dunkerson wrote:
- Tim Starling wrote:
The extension for mathematical expressions and conditional constructs has been enabled on all Wikimedia wikis, on a trial basis. Documentation is at:
http://meta.wikimedia.org/wiki/ParserFunctions
See the talk page for discussion.
Great! Wonderful job Tim! This is wonderful and will vastly simplify tons of things.
When Tim says "trial", how is the testing coordinated? Shouldn't it be tried on a few not too prominent places, rather than fix every qif now?
Where should I be looking for posts coordinating this?
The main reason I'm calling it a trial is to avoid appearing to have made a unilateral decision to enable it permanently. The critics of this concept now have one final chance to turn community opinion against it, before it becomes ingrained. However the reception has generally been positive. I've received a number of private compliments on it, in addition to what can be seen publically.
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
On 14/04/06, Tels nospam-abuse@bloodgate.com 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.
I don't know if it counts as "re-inventing the wheel" when the old wheel is not available. There is no workable alternative to these parser functions, correct? And the only partial alternatives were more Flindstone vehicles than proper wheels...
Steve
Steve Bennett wrote:
On 14/04/06, Tels nospam-abuse@bloodgate.com 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.
I don't know if it counts as "re-inventing the wheel" when the old wheel is not available. There is no workable alternative to these parser functions, correct? And the only partial alternatives were more Flindstone vehicles than proper wheels...
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 Sat, Apr 15, 2006 at 09:07:09AM +1000, Tim Starling wrote:
I don't know if it counts as "re-inventing the wheel" when the old wheel is not available. There is no workable alternative to these parser functions, correct? And the only partial alternatives were more Flindstone vehicles than proper wheels...
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.
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
On Fri, 14 Apr 2006 13:51:58 +1000 Tim Starling t.starling@physics.unimelb.edu.au wrote:
The main reason I'm calling it a trial is to avoid appearing to have made a unilateral decision to enable it permanently. The critics of this concept now have one final chance to turn community opinion against it, before it becomes ingrained. However the reception has generally been positive. I've received a number of private compliments on it, in addition to what can be seen publically.
There's also the possibility of bugs and syntax changes. We've already had one syntax change: I changed the whitespace handling in #if to mirror the behaviour in template parameters, to allow for easier conversion and neater multi-line syntax. There's also a pending suggestion to allow whitespace between the #if and the colon, and a suggestion to make #if treat "0" as true, both of which may well be implemented.
One of Gangleri's syntax suggestions sounded quite reasonable and I may well implement it. The idea if I understand it correctly was to treat pipe characters beyond the specified maximum number of arguments literally, e.g. {{#if: 1 || literal pipe: | }}.
-- Tim Starling
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]]
Tim Starling wrote:
William Allen Simpson wrote:
Conrad Dunkerson wrote: When Tim says "trial", how is the testing coordinated? Shouldn't it be tried on a few not too prominent places, rather than fix every qif now?
Where should I be looking for posts coordinating this?
The main reason I'm calling it a trial is to avoid appearing to have made a unilateral decision to enable it permanently. The critics of this concept now have one final chance to turn community opinion against it, before it becomes ingrained. However the reception has generally been positive. I've received a number of private compliments on it, in addition to what can be seen publically.
OK, here's another public compliment! Thank you!
There's also the possibility of bugs and syntax changes. We've already had one syntax change: I changed the whitespace handling in #if to mirror the behaviour in template parameters, to allow for easier conversion and neater multi-line syntax.
Yes, that's great.
... There's also a pending suggestion to allow whitespace between the #if and the colon, and a suggestion to make #if treat "0" as true, both of which may well be implemented.
Please don't implement either of these.
It doesn't make sense to have whitespace between the # and the if, and no demonstrable reason to have it before the colon.
The logic of qif was often confusing. There's only very short term advantage to backward compatibility. Having #eval and #if work like other languages will be easiest to document in the long term. Remember, features aren't of much use without easy to understand documentation.
One of Gangleri's syntax suggestions sounded quite reasonable and I may well implement it. The idea if I understand it correctly was to treat pipe characters beyond the specified maximum number of arguments literally, e.g. {{#if: 1 || literal pipe: | }}.
Actually, the trailing pipe doesn't sound reasonable to me, as it only works with "else" parameters, requiring logic to be inverted. There's a couple of fairly simple alternatives (standard html syntax, or the {{!}} template), and they work in a consistent, predictable, symmetric manner. Again, ease of documentation.
On 4/14/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
Please don't implement either of these.
It doesn't make sense to have whitespace between the # and the if, and no demonstrable reason to have it before the colon.
For formatting, to make it easier to read.
The logic of qif was often confusing. There's only very short term advantage to backward compatibility. Having #eval and #if work like other languages will be easiest to document in the long term. Remember, features aren't of much use without easy to understand documentation.
Having #if test for blank/non-blank makes more sense. #ifexpr now wraps what would have previously been a call to #if *and* #expr into a single call. If you still need to test against 0 or 1, you can use #ifeq.
Actually, the trailing pipe doesn't sound reasonable to me, as it only works with "else" parameters, requiring logic to be inverted. There's a couple of fairly simple alternatives (standard html syntax, or the {{!}} template), and they work in a consistent, predictable, symmetric manner. Again, ease of documentation.
Agreed, this is a bad idea IMO. There's a better idea on Meta at [[Talk:ParserFunctions]] to allow "wikisyntax" between {{#: <syntax> }} (I think it's mentioned here on the mailing list too), and this seems like a very good idea IMO. It would allow full wiki-table markup to be included inside conditionals (so those annoyed by XHTML could stick with what they know/like, in theory).
-L
Locke Cole wrote:
On 4/14/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
It doesn't make sense to have whitespace between the # and the if, and no demonstrable reason to have it before the colon.
For formatting, to make it easier to read.
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 logic of qif was often confusing. There's only very short term advantage to backward compatibility. Having #eval and #if work like other languages will be easiest to document in the long term. Remember, features aren't of much use without easy to understand documentation.
Having #if test for blank/non-blank makes more sense. #ifexpr now wraps what would have previously been a call to #if *and* #expr into a single call. If you still need to test against 0 or 1, you can use #ifeq.
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?
On 4/14/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
I've never found adding a space before the colon at the end of a sentence fragment to be easier to read, either.
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.
So, it should be called "#ifdef:" to match ingrained expectations. Could "#if:" be quickly retired?
#if is shorter which is probably why it'll be kept as-is.
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?
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]]).
"#ifeq:" is for matching strings, not against "0". See what I mean about ingrained expectations?
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:
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> }}
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> }}
Note also that the result strings are also trimmed of whitespace, so the CR/LF are ignored.
Yeah, saw that in the code.
So, it should be called "#ifdef:" to match ingrained expectations. Could "#if:" be quickly retired?
#if is shorter which is probably why it'll be kept as-is.
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 proposed it on the talk page a little while ago (which is where most discussion is going on right now).
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 4/15/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
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.
Maybe this is the devs hinting that they don't want to turn wikisyntax into a fully fledged programming language. Make people stop and think "hey, this isn't exactly the same implementation as in so-and-so language... oh wait, that's right, this isn't so-and-so langauge, it's just wikisyntax."
-- Stephen Bain stephen.bain@gmail.com
Stephen Bain wrote:
On 4/15/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
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.
Maybe this is the devs hinting that they don't want to turn wikisyntax into a fully fledged programming language.
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.
... Make people stop and think "hey, this isn't exactly the same implementation as in so-and-so language... oh wait, that's right, this isn't so-and-so langauge, it's just wikisyntax."
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?
William Allen Simpson wrote:
Stephen Bain wrote:
Maybe this is the devs hinting that they don't want to turn wikisyntax into a fully fledged programming language.
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.
I assure you it's entirely ad hoc jiggery pokery. :)
Hopefully we'll get it sorted out and formally defined "soon". (It would be a lot easier to get reliable wysiwyg editing going with reliable transformations.)
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
William Allen Simpson wrote:
Stephen Bain wrote:
Maybe this is the devs hinting that they don't want to turn wikisyntax into a fully fledged programming language.
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.
I assure you it's entirely ad hoc jiggery pokery. :)
Well, picture my jaw hitting the floor.
Hopefully we'll get it sorted out and formally defined "soon". (It would be a lot easier to get reliable wysiwyg editing going with reliable transformations.)
Please add to the Summer of Code projects. I'm over a quarter century out of date on the latest language theory and tools, but serious students will be most helpful in this area.
I'd put edit input syntax checking ahead of wysiwyg. I'm sure I'm not the only one that gets bored fixing bad links and tables.
Conrad Dunkerson wrote:
- Tim Starling wrote:
The extension for mathematical expressions and conditional constructs has been enabled on all Wikimedia wikis, on a trial basis. Documentation is at:
http://meta.wikimedia.org/wiki/ParserFunctions
See the talk page for discussion.
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! :]
Hoi, I do understand from Gangleri that this new functionality is horribly broken when it comes to right to left languages. I take it this code is still very much experimental until it works properly for *all *the languages Wikimedia uses MediaWiki for. It would therefore be better to wait replacing templates until this functionality works properly.
Thanks, GerardM
Gerard Meijssen wrote:
I do understand from Gangleri that this new functionality is horribly broken when it comes to right to left languages.
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.*
I take it this code is still very much experimental until it works properly for *all *the languages Wikimedia uses MediaWiki for. It would therefore be better to wait replacing templates until this functionality works properly.
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)
Brion Vibber wrote:
Gerard Meijssen wrote:
I do understand from Gangleri that this new functionality is horribly broken when it comes to right to left languages.
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:
Localized (thus right-to-left) keywords can be provided if necessary.
Numbers are left-to-right even in the right-to-left scripts. *You thus cannot
avoid mixed-directionality text when doing "math" stuff.*
I take it this code is still very much experimental until it works properly for *all *the languages Wikimedia uses MediaWiki for. It would therefore be better to wait replacing templates until this functionality works properly.
and most importantly:
- 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.
Hoi, The argument does not fall on its face; it only proves again that MediaWiki is hard, arguably impossible for many, to use for languages that are not left to right. Templates are constructs and they tend to be local to a particular project. When the keywords are such that they are based on choices based on the expectation of left to right languages they are inherently broken for right to left languages.
Often it has been discussed why a Wikipedia project like Arab is not doing as well as expected; one reason often denied is because it is hard to understand the editing process. The net result of this 'confusion' is that people find it too difficult to edit. From a user experience it is MediaWiki that is broken. If we also need to cooperate with Mozilla, Opera, Apple and Microsoft to fix this it where the browser is to blame, we should.
Thanks, GerardM
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
On 13/04/06, Erik Moeller eloquence@gmail.com wrote:
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.
I have maintained this position for a long time. Certain of the developers do "adopt" languages and keep their localisations up to date, and Rotem Liss seems to have placed himself in charge of keeping the Hebrew localisation up-to-the-minute, but I think we could do better than that.
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.
Concur.
Rob Church
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)
Hoi, Horribly broken is when it is not usable for an ordinary user. I was not an ordinary user when I started editing in Farsi and, has been a real education; it was horrible, it was broken. The only reason why I finished the things I wanted done was because I used multiple browsers for different tasks. Something that would take five minutes in Dutch or English would take at least half an hour.
What is needed to have proper support for language is to have developers who know these languages, know it as their mother language. Who make sure that MediaWiki does not even have to suffer from "minor" annoyances. Annoyances that would not be accepted for English.
It is rich that we feel this need to debate about what the main reason is why we do poorly in left to right languages. All this talk is a great excuse to do nothing. My answer is that the reason is a mix of issues. When you change this mix by making it easier/possible to edit, it will certainly change the potential for more contributions.
Thanks, Gerard
On 4/13/06, Erik Moeller eloquence@gmail.com wrote:
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 _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Gerard Meijssen wrote:
The argument does not fall on its face; it only proves again that MediaWiki is hard, arguably impossible for many, to use for languages that are not left to right.
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)
Brion Vibber wrote:
Gerard Meijssen wrote:
The argument does not fall on its face; it only proves again that MediaWiki is hard, arguably impossible for many, to use for languages that are not left to right.
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)
Hoi, The current functionality is not good enough. The argument that the new stuff does not make the situation worse is wrong. People argued that the new functionality will make it harder for many even in left to right languages. It becomes therefore even more problematic to use the constructs that are now considered in right to left languages.
The current stuff is broken, the fact that the proposed new stuff is broken in the same way does not make it an excuse. Please remember what our objective is: information for all people in their language.
Thanks, GerardM
Gerard Meijssen wrote:
The current stuff is broken, the fact that the proposed new stuff is broken in the same way does not make it an excuse. Please remember what our objective is: information for all people in their language.
At this point it might be appropriate for the people complaining about it being broken to propose a syntax the _would_ work for them. Doesn't have to be perfect, just something to give us LTR-writing folks something more concrete to work on than "it doesn't work".
On Thu, 13 Apr 2006 23:16:27 +0300 Ilmari Karonen nospam@vyznev.net wrote:
Gerard Meijssen wrote:
The current stuff is broken, the fact that the proposed new stuff is broken in the same way does not make it an excuse. Please remember what our objective is: information for all people in their language.
At this point it might be appropriate for the people complaining about it being broken to propose a syntax the _would_ work for them. Doesn't have to be perfect, just something to give us LTR-writing folks something more concrete to work on than "it doesn't work".
-- Ilmari Karonen
Dear Ilmari, Would you prefere a wording "It is not practical"?
Please go at http://yi.wiktionary.org/w/index.php?title=template:listspecial&action=e... I copied the template from Rob's testwiki because you would need to login.
This is a typical "all in one line template" designed at a LTR wiki and pasted here. No additional complications because of Hebrew characters.
To see that the template is functional take a look at http://yi.wiktionary.org/wiki/project:Special_pages/%21list
I would not thouch that to spend my time.
Now go to http://yi.wiktionary.org/w/index.php?title=%D7%B0%D7%90%D6%B7%D7%A1%D7%A2%D7...
this is an old draft waiting for optimization trough conditional templates.
Nothing special. Beleive me that RTL / BiDi editing is complicated enougt and there is no need for more workarounds / restictions.
reinhardt [[user:gangleri]]
Reinhardt WIEWE @ torg.is wrote:
Now go to http://yi.wiktionary.org/w/index.php?title=%D7%B0%D7%90%D6%B7%D7%A1%D7%A2%D7...
this is an old draft waiting for optimization trough conditional templates.
Nothing special. Beleive me that RTL / BiDi editing is complicated enougt and there is no need for more workarounds / restictions.
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.
On Fri, 14 Apr 2006 00:27:15 +0300 Ilmari Karonen nospam@vyznev.net wrote:
Reinhardt WIEWE @ torg.is wrote:
Now go to
http://yi.wiktionary.org/w/index.php?title=%D7%B0%D7%90%D6%B7%D7%A1%D7%A2%D7...
this is an old draft waiting for optimization trough conditional templates.
Nothing special. Beleive me that RTL / BiDi editing is complicated enougt
and
there is no need for more workarounds / restictions.
Yes, I can see that it's a mess. But what would you propose instead?
Improuvements in small steps:
a) Bug 4011: Allow users to change text direction in all text input and textarea boxes == http://bugzilla.wikimedia.org/show_bug.cgi?id=4011
http://yi.wiktionary.org/wiki/user:Gangleri/tests/bugzilla#RTL_.26_Bidi_issu... lists all RTL and bidirectional projects (striked projects are not set up)
When you edit http://ar.wikipedia.org/wiki/project/sandbox/do_not_save?action=edit as an anonimuous user you will see that the cursor is at the right if you log in you will see that the cursor is at the left the same will happen at http://he.wikipedia.org/w/index.php?title=Project/sandbox/do_not_save&ac... but at http://fa.wikipedia.org/w/index.php?title=Project/sandbox/do_not_save&ac... http://ur.wikipedia.org/w/index.php?title=Project/sandbox/do_not_save&ac... http://ug.wikipedia.org/w/index.php?title=Project/sandbox/do_not_save&ac... the cursor will be always at the right
BTW: I discovered the difference at ar: and he: just now.
Facilitate bidirectional editing / readability via a trailing escape character (as "") at the end of line == http://bugzilla.wikimedia.org/show_bug.cgi?id=05121 realy would be an improuvement
you may see that this is also a workaround for the bug demonstarted at http://meta.wikimedia.org/wiki/Talk:ParserFunctions#note_on_usage_of_whitesp...
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
The question if it "be easier to edit if it was _all_ in Hebrew, with no Latin letters at all?" does not focus on the main problem.
Content, contributor names, variables, parameters would be more and more mixed. Of course it would be more easier if a single script would be used. But it can be made "less complicated" also.
http://epov.org/wd-gemet/index.php/Template_talk:dir_rtl is a template to include RTL text in a LTR environment and http://yi.wikipedia.org/wiki/template_talk:dir_ltr is a template to include LTR text in a RTL environment.
There should be some copies around at various projects. They can be improuved because padding is not necessary.
The templates are used / can be used inside articles, pages, project and hep pages.
To answer your question: I neither untherstand Arabic, Dari, Farsi, Hebrew, Kurdish, Pashto, Sindhi, Urdu etc. I have some minimal knowledge of Yiddish.
Keeping keywords in English would help me to provide some support. For the native speakers a translation is more suitable.
But one can provide support also either useing 'project', '{{ns:project}}' or '{{subst:ns:project}}'.
Thanks for your interest on this topic. If you spend months to find out all what's possible and what is not you can not explain this in a few minutes. However it should not take that long once the knowledge is available.
best regards reinhardt [[user:gangleri]]
On Thu, Apr 13, 2006 at 10:09:48PM +0200, Gerard Meijssen wrote:
Brion Vibber wrote:
Gerard Meijssen wrote:
The argument does not fall on its face; it only proves again that MediaWiki is hard, arguably impossible for many, to use for languages that are not left to right.
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.
The current functionality is not good enough. The argument that the new stuff does not make the situation worse is wrong. People argued that the new functionality will make it harder for many even in left to right languages. It becomes therefore even more problematic to use the constructs that are now considered in right to left languages.
The current stuff is broken, the fact that the proposed new stuff is broken in the same way does not make it an excuse. Please remember what our objective is: information for all people in their language.
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
On Thu, 13 Apr 2006 12:29:58 -0700 Brion Vibber brion@pobox.com 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.
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#special... http://www.anubite.co.uk/mediawiki/head-rtl/index.php/Mw16:Special_pages/%21... http://www.anubite.co.uk/wikis/test-fpr/index.php/Farsitest:Special_pages/%2...
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:
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)
best regards reinhardt [[user:gangleri]]
Reinhardt WIEWE @ torg.is wrote:
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:
You can already have line breaks here, can't you?
-- brion vibber (brion @ pobox.com)
On Thu, 13 Apr 2006 15:25:57 -0700 Brion Vibber brion@pobox.com wrote:
Reinhardt WIEWE @ torg.is wrote:
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:
You can already have line breaks here, can't you?
-- brion vibber (brion @ pobox.com)
Unfortunatelly not everywhere: http://meta.wikimedia.org/wiki/Talk:ParserFunctions#note_on_usage_of_whitesp... shows a *general template* example with a parameter having a trailing new line which will breake in a construct as [[user:{{{bar}}}|{{{bar}}}]].
the last two test regarding {{#if: ... }} render fine http://meta.wikimedia.org/wiki/Talk:ParserFunctions#Notes_on_syntax
http://bugzilla.wikimedia.org/show_bug.cgi?id=05121 relates also to list items where a new line would break the syntax
best regards reinhardt [[user:gangleri]]
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.
William Allen Simpson wrote:
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.
Well, we work in a Unicode/XML/HTML context, and for better or for worse the W3C world has explicitly embraced bidirectional text stored in logical order.
Parsing of markup happens on text in logical order. Since the markup is very much embedded in the text and requires both exposure to human editors and consistent parsing by the machine, I'm not sure that e-mail is a good comparison. The 'markup' in e-mail is invisible to the user: headers, escape codes, MIME content part separators.
Our output is to HTML, and editing is done in a web browser. This is a heavily bidi-centric environment which I don't think we could really override if we wanted to.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
William Allen Simpson wrote:
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.
Well, we work in a Unicode/XML/HTML context, and for better or for worse the W3C world has explicitly embraced bidirectional text stored in logical order.
Yes, that's good, a canonical form for storage.
Parsing of markup happens on text in logical order. Since the markup is very much embedded in the text and requires both exposure to human editors and consistent parsing by the machine, I'm not sure that e-mail is a good comparison. The 'markup' in e-mail is invisible to the user: headers, escape codes, MIME content part separators.
But not when editing. The edits are handled by specific MUA. Some expose the raw markup, others hide the markup and handle the conversions.
Our output is to HTML, and editing is done in a web browser. This is a heavily bidi-centric environment which I don't think we could really override if we wanted to.
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?
Brion Vibber wrote:
Well, we work in a Unicode/XML/HTML context, and for better or for worse the W3C world has explicitly embraced bidirectional text stored in logical order.
Parsing of markup happens on text in logical order. Since the markup is very much embedded in the text and requires both exposure to human editors and consistent parsing by the machine, I'm not sure that e-mail is a good comparison. The 'markup' in e-mail is invisible to the user: headers, escape codes, MIME content part separators.
As a followup, a little searching found: http://www.w3.org/TR/REC-html40/struct/dirlang.html
Amazingly, this references Hank's work on email mentioned earlier: http://www.w3.org/TR/REC-html40/references.html#ref-RFC1555 http://www.w3.org/TR/REC-html40/references.html#ref-RFC1556
Our output is to HTML, and editing is done in a web browser. This is a heavily bidi-centric environment which I don't think we could really override if we wanted to.
On Thu, Apr 13, 2006 at 09:11:28PM -0400, William Allen Simpson wrote:
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.
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 wrote:
On Thu, Apr 13, 2006 at 09:11:28PM -0400, William Allen Simpson wrote:
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.
Note that there are many lists related to MediaWiki and Wikimedia Foundation issues; it's possible that you're on the wrong one.
Say Jay, you're as acerbic as ever. Anything's possible. Any suggestions?
On Fri, Apr 14, 2006 at 11:14:21AM -0400, William Allen Simpson wrote:
Jay R. Ashworth wrote:
On Thu, Apr 13, 2006 at 09:11:28PM -0400, William Allen Simpson wrote:
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.
Note that there are many lists related to MediaWiki and Wikimedia Foundation issues; it's possible that you're on the wrong one.
Say Jay, you're as acerbic as ever. Anything's possible. Any suggestions?
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 wrote:
On Fri, Apr 14, 2006 at 11:14:21AM -0400, William Allen Simpson wrote:
Jay R. Ashworth wrote:
On Thu, Apr 13, 2006 at 09:11:28PM -0400, William Allen Simpson wrote:
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.
Note that there are many lists related to MediaWiki and Wikimedia Foundation issues; it's possible that you're on the wrong one.
Say Jay, you're as acerbic as ever. Anything's possible. Any suggestions?
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.
Unfortunately, most of the mailing list discussion on technical issues such as hardware and colocation seems to be on private-l. That's still a low volume list though, there's much more action on IRC. The best place to get involved with operational issues at present is the #wikimedia-tech channel on irc.freenode.net. Also have a look at https://wikitech.leuksman.com/
-- Tim Starling
William Allen Simpson wrote:
(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.
The major difficulty, based on what I've seen, seem to be parentheses and other punctuation in mixed LTR/RTL text. The browsers try to guess which way these should be displayed, but they're not very good at it.
This isn't much of a problem in the displayed content, since there we can use <span> tags to explictly set the directionality, but in the edit box. Ironically, HTML tags themselves are a problem when embedded in RTL text, since they themselves consist of LTR text surrounded by paired delimiters. For example, if the source of a page contained, in storage order, the string "HE<span>BR</span>EW", where the capitals stand for Hebrew letters, it may render in the edit box as "WEspan>/>RBspan>>EH". Not very easy to edit, is it?
As a practical suggestion, it might be a good idea to set the CSS property "unicode-bidi: bidi-override;" for the edit box. That should, in browsers that understand it, force all the text in the edit box to render in the same direction. That way, on a RTL wiki, the example string above would render as "WE<naps/>RB<naps>EH", which at least is less confusing than the current rendering.
In fact, I just tested it by adding:
FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }
to my monobook.css on yi.wiktionary and it seems to work. Gangleri, can you try this and say if it helps any?
On Fri, 14 Apr 2006 16:01:48 +0300 Ilmari Karonen nospam@vyznev.net wrote:
William Allen Simpson wrote:
In fact, I just tested it by adding:
FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }
to my monobook.css on yi.wiktionary and it seems to work. Gangleri, can you try this and say if it helps any?
-- Ilmari Karonen
Thanks Ilmari for the suggestion.
Niklas and Rob suggested http://yi.wiktionary.org/w/index.php?title=user:Nikerabbit/monobook.css&... form#editform textarea#wpTextbox1 { direction: ltr } form#editform input#wpSummary { direction: ltr }
This is just a part of the interface. It does not cover search, move, delete, undelete, block etc. fields
Editing RTL in MediaWiki is a mather of practice. As requested in
Allow users to change text direction in all text input and textarea boxes http://bugzilla.wikimedia.org/show_bug.cgi?id=4011
the change from LTR to RTL editing and viceversa should be as easy as possible. I would realy be happy to have a choice in 'special:Preferences'.
Anonymous editors would not have this posibility. If they accept cookies one could offer two radio buttons for a 'LTR' or 'RTL' choice.
reinhardt [[user:gangleri]]
Reinhardt WIEWE @ torg.is wrote:
In fact, I just tested it by adding:
FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }
to my monobook.css on yi.wiktionary and it seems to work. Gangleri, can you try this and say if it helps any?
-- Ilmari Karonen
Thanks Ilmari for the suggestion.
It wasn't a suggestion, it was a question. Please say whether it helps?
Niklas and Rob suggested http://yi.wiktionary.org/w/index.php?title=user:Nikerabbit/monobook.css&... form#editform textarea#wpTextbox1 { direction: ltr } form#editform input#wpSummary { direction: ltr }
But that just makes everything ltr. Not what was under discussion here.
This is just a part of the interface. It does not cover search, move, delete, undelete, block etc. fields
Editing RTL in MediaWiki is a mather of practice. As requested in
Allow users to change text direction in all text input and textarea boxes http://bugzilla.wikimedia.org/show_bug.cgi?id=4011
the change from LTR to RTL editing and viceversa should be as easy as possible. I would realy be happy to have a choice in 'special:Preferences'.
Anonymous editors would not have this posibility. If they accept cookies one could offer two radio buttons for a 'LTR' or 'RTL' choice.
But not possible to be addressed until folks know the technical solution. Stay focused. Does bidi-override help with template edits?
On Fri, 14 Apr 2006 11:53:17 -0400 William Allen Simpson william.allen.simpson@gmail.com wrote:
Reinhardt WIEWE @ torg.is wrote:
In fact, I just tested it by adding:
FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }
to my monobook.css on yi.wiktionary and it seems to work. Gangleri, can you try this and say if it helps any?
-- Ilmari Karonen
Thanks Ilmari for the suggestion.
It wasn't a suggestion, it was a question. Please say whether it helps?
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.
Niklas and Rob suggested
http://yi.wiktionary.org/w/index.php?title=user:Nikerabbit/monobook.css&...
form#editform textarea#wpTextbox1 { direction: ltr } form#editform input#wpSummary { direction: ltr }
But that just makes everything ltr. Not what was under discussion here.
"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.
This is just a part of the interface. It does not cover search, move,
delete,
undelete, block etc. fields
Editing RTL in MediaWiki is a mather of practice. As requested in
Allow users to change text direction in all text input and textarea boxes http://bugzilla.wikimedia.org/show_bug.cgi?id=4011
the change from LTR to RTL editing and viceversa should be as easy as
possible.
I would realy be happy to have a choice in 'special:Preferences'.
Anonymous editors would not have this posibility. If they accept cookies
one
could offer two radio buttons for a 'LTR' or 'RTL' choice.
But not possible to be addressed until folks know the technical solution. Stay focused. Does bidi-override help with template edits?
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]]
On Fri, 14 Apr 2006 11:53:17 -0400 William Allen Simpson william.allen.simpson@gmail.com wrote:
Reinhardt WIEWE @ torg.is wrote:
In fact, I just tested it by adding:
FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }
to my monobook.css on yi.wiktionary and it seems to work. Gangleri, can you try this and say if it helps any?
-- Ilmari Karonen
Thanks Ilmari for the suggestion.
It wasn't a suggestion, it was a question. Please say whether it helps?
{ unicode-bidi: bidi-override; } would not help at http://yi.wiktionary.org/w/index.php?title=template:tsayt_-_divisions&ac... http://yi.wiktionary.org/w/index.php?title=template:vokh_-_divisions&act...
neither { direction: ltr; unicode-bidi: bidi-override; }
It is a workaround: you can see syntax errors but if you would need to edit you would start making spelling errors in the 'mirrored' script.
best regards reinhardt [[user:gangleri]]
Reinhardt WIEWE @ torg.is wrote:
On Fri, 14 Apr 2006 11:53:17 -0400 William Allen Simpson william.allen.simpson@gmail.com wrote:
Reinhardt WIEWE @ torg.is wrote:
In fact, I just tested it by adding:
FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }
[snip]
It wasn't a suggestion, it was a question. Please say whether it helps?
As a testing hack I've set up control buttons on one of our test wikis to change the CSS 'direction' and 'unicode-bidi' values at edit time.
Here's a copy of the Hebrew Wikipedia main page source; since the test wiki is LTR it shows LTR by default, but you can switch the edit box around with the buttons: http://test.leuksman.com/edit/New_page
(Briefly tested in Firefox 1.5.0.2 and Safari 2.0.3.)
It's pretty ugly, but being able to switch in the unidirectional mode at will might be helpful.
The JS: http://test.leuksman.com/extensions/BidiSwitch/switch.js
-- brion vibber (brion @ pobox.com)
On Fri, 14 Apr 2006 17:39:25 -0700 Brion Vibber brion@pobox.com wrote:
Reinhardt WIEWE @ torg.is wrote:
On Fri, 14 Apr 2006 11:53:17 -0400
[snip] ... { unicode-bidi: bidi-override; } [snip]
It wasn't a suggestion, it was a question. Please say whether it helps?
As a testing hack I've set up control buttons on one of our test wikis to change the CSS 'direction' and 'unicode-bidi' values at edit time.
Here's a copy of the Hebrew Wikipedia main page source; since the test wiki is LTR it shows LTR by default, but you can switch the edit box around with the buttons: http://test.leuksman.com/edit/New_page
(Briefly tested in Firefox 1.5.0.2 and Safari 2.0.3.)
It's pretty ugly, but being able to switch in the unidirectional mode at will might be helpful.
The JS: http://test.leuksman.com/extensions/BidiSwitch/switch.js
-- brion vibber (brion @ pobox.com)
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]]
On Fri, 14 Apr 2006 17:39:25 -0700 Brion Vibber brion@pobox.com wrote:
[snip]
It wasn't a suggestion, it was a question. Please say whether it helps?
As a testing hack I've set up control buttons on one of our test wikis to change the CSS 'direction' and 'unicode-bidi' values at edit time.
Here's a copy of the Hebrew Wikipedia main page source; since the test wiki is LTR it shows LTR by default, but you can switch the edit box around with the buttons: http://test.leuksman.com/edit/New_page
(Briefly tested in Firefox 1.5.0.2 and Safari 2.0.3.)
It's pretty ugly, but being able to switch in the unidirectional mode at will might be helpful.
The JS: http://test.leuksman.com/extensions/BidiSwitch/switch.js
-- brion vibber (brion @ pobox.com)
I forgot to mention that when using Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2 I have problems seeing <br> (which I changed to <br />). I experienced this (character overlapping) in the past when editing Hindi, Gujarati (and similar script) pages.
A benefit from pasting a page into a wiki with different namespaces: One can see the usage of {{template:foo}} == {{muster:foo}} which renders as {{template:muster:foo}} etc. http://test.leuksman.com/history/%D7%A2%D7%A8%D7%A9%D7%98%D7%A2_%D7%96%D7%B2...
best regards reinhardt [[user:gangleri]]
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:
Reinhardt WIEWE @ torg.is wrote:
On Fri, 14 Apr 2006 11:53:17 -0400 William Allen Simpson william.allen.simpson@gmail.com wrote:
Reinhardt WIEWE @ torg.is wrote:
In fact, I just tested it by adding:
FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }
[snip]
It wasn't a suggestion, it was a question. Please say whether it helps?
As a testing hack I've set up control buttons on one of our test wikis to change the CSS 'direction' and 'unicode-bidi' values at edit time.
Here's a copy of the Hebrew Wikipedia main page source; since the test wiki is LTR it shows LTR by default, but you can switch the edit box around with the buttons: http://test.leuksman.com/edit/New_page
(Briefly tested in Firefox 1.5.0.2 and Safari 2.0.3.)
It's pretty ugly, but being able to switch in the unidirectional mode at will might be helpful.
The JS: http://test.leuksman.com/extensions/BidiSwitch/switch.js
-- brion vibber (brion @ pobox.com)
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 14/04/06, Reinhardt WIEWE @ torg.is gangleri@torg.is wrote:
Niklas and Rob suggested http://yi.wiktionary.org/w/index.php?title=user:Nikerabbit/monobook.css&... form#editform textarea#wpTextbox1 { direction: ltr } form#editform input#wpSummary { direction: ltr }
As it happens, I didn't. I took Ilmari's CSS suggestion
form#editform textarea#wpTextbox1 { bidi: bidi-overriide; }
and put it live on a test wiki, then asked Gangleri to check it. He seemed to have been in a discussion with Niklas prior to that.
I've had occasion to edit the RTL test wiki a couple of times (testing other, simpler RTL issue fixes) and as far as I notice right now, with the patch, the wikitext doesn't seem to "play silly buggers" in the text box so much.
Rob Church
"Reinhardt WIEWE @ torg.is" gangleri@torg.is escribió en el mensaje news:web-153858978@heimsnet.is... (....)
Editing RTL in MediaWiki is a mather of practice. As requested in
Allow users to change text direction in all text input and textarea boxes http://bugzilla.wikimedia.org/show_bug.cgi?id=4011
the change from LTR to RTL editing and viceversa should be as easy as possible. I would realy be happy to have a choice in 'special:Preferences'.
Anonymous editors would not have this posibility. If they accept cookies one could offer two radio buttons for a 'LTR' or 'RTL' choice.
reinhardt [[user:gangleri]]
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
Ilmari Karonen wrote:
William Allen Simpson wrote:
(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.
The major difficulty, based on what I've seen, seem to be parentheses and other punctuation in mixed LTR/RTL text. The browsers try to guess which way these should be displayed, but they're not very good at it.
This isn't much of a problem in the displayed content, since there we can use <span> tags to explictly set the directionality, but in the edit box. Ironically, HTML tags themselves are a problem when embedded in RTL text, since they themselves consist of LTR text surrounded by paired delimiters. For example, if the source of a page contained, in storage order, the string "HE<span>BR</span>EW", where the capitals stand for Hebrew letters, it may render in the edit box as "WEspan>/>RBspan>>EH". Not very easy to edit, is it?
Aha, I'd not considered that this problem would also occur with the HTML markup itself. Seems like the same problem as templates.
As a practical suggestion, it might be a good idea to set the CSS property "unicode-bidi: bidi-override;" for the edit box. That should, in browsers that understand it, force all the text in the edit box to render in the same direction. That way, on a RTL wiki, the example string above would render as "WE<naps/>RB<naps>EH", which at least is less confusing than the current rendering.
I only knew about "<BDO>...</BDO>" but not "bidi-override;" for entire sections, very clever.
In fact, I just tested it by adding:
FORM#editform TEXTAREA#wpTextbox1 { unicode-bidi: bidi-override; }
to my monobook.css on yi.wiktionary and it seems to work. Gangleri, can you try this and say if it helps any?
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?
wikitech-l@lists.wikimedia.org