I'm playing with MediaWiki code, and have added the ability of parsing HTML-like tags: for example, <red>text</red> would display text in red color. Is this interesting enough to be included in the code?
This was mentioned a month ago in the "support for <span> tags" thread. Aside from being easier to remember and type then <font color=red> it would also produce HTML without now deprecated <font> tags.
I also have a question: when $wgUseDatabaseMessages is set to false, use of {{msg:}} tags is disabled as well. Is this intended? If yes, why? I would like to fix this, but cannot figure out how.This problem is apparent on Serbian and, i guess, other non-English Wikipedias: LanguageSr.php is not copied to database, so database messages must be disabled, but that forces {{msg:}} tags not to work.
"Nikola Smolenski" smolensk@eunet.yu wrote in message news:200403131038.32045.smolensk@eunet.yu...
I'm playing with MediaWiki code, and have added the ability of parsing HTML-like tags: for example, <red>text</red> would display text in red color. Is this interesting enough to be included in the code?
This was mentioned a month ago in the "support for <span> tags" thread. Aside from being easier to remember and type then <font color=red> it would also produce HTML without now deprecated <font> tags.
I don't know, I'm not a big fan of HTML-like tags. The general idea of wikitext is to use a markup which is easy to type, rather than easy to parse.
I also have a question: when $wgUseDatabaseMessages is set to false, use of {{msg:}} tags is disabled as well. Is this intended? If yes, why? I would like to fix this, but cannot figure out how.
Aaahh, don't touch! ;) I'm changing this part of the code completely. It's mostly ready to go.
This problem is apparent on Serbian and, i guess, other non-English Wikipedias: LanguageSr.php is not copied to database, so database messages must be disabled, but that forces {{msg:}} tags not to work.
The best thing to do is to get the language file copied into the database. This is easy to do, I imagine it will get done even before the code changes I mentioned above.
-- Tim Starling
"Tim Starling" ts4294967296@hotmail.com writes:
I don't know, I'm not a big fan of HTML-like tags. The general idea of wikitext is to use a markup which is easy to type, rather than easy to parse.
BTW, on international keyboards (e.g., on a german one) "{}[]|" (and more) are not easy to type - this is why I use a keyboard with a US layout ;)
Let's stop adding cryptic layout/markup commands; go for XML and contributors can use their XML editors or browser plugins. etc. pp.
Wikimedia developers wikitech-l@Wikipedia.org writes:
Let's stop adding cryptic layout/markup commands; go for XML and contributors can use their XML editors or browser plugins. etc. pp.
You're forgetting who the wikipedia user base is. XML really isn't meant to be edited and used by humans despite its ASCII syntax, it is a program to program interface. HTML isn't much better. The built-in XML editors of browsers are terrible. All but XML mavens do not have other XML tools readily available.
The whole idea of the wiki markup is to provide an easy markup that is not too intimidating to non-technical people. Even the wiki markup is very intimidating to technophobes who are otherwise highly intelligent people. So a lot of thought should go into any additions to the wiki markup before being implemented.
Opinion: XML is one of the worst "languages" to code in and read that I have personally encountered in my 42 years of writing software. Don't confuse regularity with ease of use. An extreme example is XSLT which uses XML format. Descriptions written in it are almost totally undecipherable except by deep analysis.
Nick Pisarro
On Mon, 15 Mar 2004 07:44:39 -0500, Nick Pisarro wrote:
Opinion: XML is one of the worst "languages" to code in and read that I have personally encountered in my 42 years of writing software. Don't confuse regularity with ease of use. An extreme example is XSLT which uses XML format. Descriptions written in it are almost totally undecipherable except by deep analysis.
Nick Pisarro
Hello,
You must have debugged softwares using punch card as entry : http://en.wikipedia.org/wiki/Punch_card
Where they easier to read than XML ? :p
... Just having a little fun.
I do agree XML isn't for human read, but it's great to export database datas or just formatting them so they can be used by another software that will display them to human. It just another layer between 2 computer softwares.
cheers,
Wikimedia developers wikitech-l@Wikipedia.org writes:
Hello,
You must have debugged softwares using punch card as entry : http://en.wikipedia.org/wiki/Punch_card
Where they easier to read than XML ? :p
Well sure! After you printed them off using an IBM model 407 Accounting Machine of course. You could also run them through a printing key punch which would print the meaning of the holes along the top of the cards.
A fellow associate of mine would actually write programs sitting at a keypunch. A cool thing you could do, if you serialized everything using columns 72-80, was to put your changes at the end of a deck and run them through a card sorter to insert them. This worked poorly for deletions, however. I once mailed a program update to a friend by putting a stamp and address on a punch card and mailing it off.
Cards were a luxury compared to paper tape. At least you could replace cards on a one by one basis.
For unreadability, there was this language called RPG--Report Program Generator--that turned your IBM 1401 or System 360/Model 30 into an accounting machine. Each column of a card had different meanings. But RPG programs were luxuries compared to wiring a plugboard.
Then there was APL--A Programming Language--probably the champion for creating amazingly compact but totally unreadable and unmaintainable programs [the RegEx of its day], but mathematicians used to love it.
Debugging in those days often involved wading through pages and pages of core dump. We sold software to the C.I.A. They would send us core dumps with the top secret data cut out with a pair of scissors. That means some guy had to look through the dump figuring out which data was confidential.
... Just having a little fun.
I do agree XML isn't for human read, but it's great to export database datas or just formatting them so they can be used by another software that will display them to human. It just another layer between 2 computer softwares.
Absolutely. XML certainly has its place.
cheers,
Sorry for the off topic discussion.
Nick
"NP" == Nick Pisarro nickp@aperture.com writes:
NP> The whole idea of the wiki markup is to provide an easy markup NP> that is not too intimidating to non-technical people. Even the NP> wiki markup is very intimidating to technophobes who are NP> otherwise highly intelligent people. So a lot of thought NP> should go into any additions to the wiki markup before being NP> implemented.
+1
I also think getting a WYSIWYG editor going is more important:
http://meta.wikipedia.org/wiki/WYSIWYG_editor
~ESP
"Nick Pisarro" nickp@aperture.com writes:
XML really isn't meant to be edited and used by humans despite its ASCII syntax,
That's why I said "XML editor or browser plugin". But I wouldn't mind SGML with minimization features neither. The WP syntas isn't that far away from SGML.
it is a program to program interface. HTML isn't much better. The built-in XML editors of browsers are terrible. All but XML mavens do not have other XML tools readily available.
They can continue to add text between simple <para>tags</para>.
Opinion: XML is one of the worst "languages" to code in and read that I have personally encountered in my 42 years of writing software.
Only WP syntax will top XML...
Don't confuse regularity with ease of use. An extreme example is XSLT which uses XML format.
Agreed. I recommend to stick with DSSSL for transformation and formatting.
Descriptions written in it are almost totally undecipherable except by deep analysis.
Yes ;-(
On Sat, 13 Mar 2004 10:38:31 +0100, Nikola Smolenski wrote:
I'm playing with MediaWiki code, and have added the ability of parsing HTML-like tags: for example, <red>text</red> would display text in red color. Is this interesting enough to be included in the code?
This was mentioned a month ago in the "support for <span> tags" thread. Aside from being easier to remember and type then <font color=red> it would also produce HTML without now deprecated <font> tags.
Hello,
Maybe it would be better to use [red][/red] instead.
Ashar Voultoiz wrote:
On Sat, 13 Mar 2004 10:38:31 +0100, Nikola Smolenski wrote:
I'm playing with MediaWiki code, and have added the ability of parsing HTML-like tags: for example, <red>text</red> would display text in red color. Is this interesting enough to be included in the code?
This was mentioned a month ago in the "support for <span> tags" thread. Aside from being easier to remember and type then <font color=red> it would also produce HTML without now deprecated <font> tags.
Maybe it would be better to use [red][/red] instead.
Or even better yet, [!red text goes here] (becomes <span class='red'>text goes here</span>).
Am Samstag, 13. März 2004 23:17 schrieb Timwi:
Ashar Voultoiz wrote:
On Sat, 13 Mar 2004 10:38:31 +0100, Nikola Smolenski wrote:
I'm playing with MediaWiki code, and have added the ability of parsing HTML-like tags: for example, <red>text</red> would display text in red color. Is this interesting enough to be included in the code?
This was mentioned a month ago in the "support for <span> tags" thread. Aside from being easier to remember and type then <font color=red> it would also produce HTML without now deprecated <font> tags.
Maybe it would be better to use [red][/red] instead.
Or even better yet, [!red text goes here] (becomes <span class='red'>text goes here</span>).
ohh yeah... and [!bold this is bold text], [!italic this is italic text] ... or short [!b this is bold text] ...
:-)))
--Ivo Köthnig
Ivo Köthnig koethnig@web.de writes:
ohh yeah... and [!bold this is bold text], [!italic this is italic text] ... or short [!b this is bold text] ...
Or proper SGML (reference concrete syntax):
<b/this is bold text/
Ivo Köthnig wrote:
ohh yeah... and [!bold this is bold text], [!italic this is italic text] ... or short [!b this is bold text] ...
We should stick to the [..|..] style:
[please make the following text as bold, if it's not too much trouble|text] ;)
Magnus
wikitech-l@lists.wikimedia.org