https://bugzilla.wikimedia.org/show_bug.cgi?id=29530
--- Comment #11 from Markus Szumovski <[email protected]> 2011-07-03 14:52:26 UTC --- Hi! First I'll answer some questions raised and comment some of the posts. At the end of my post I'll make a proposal for date-information-standard, that is still in development by me, to be used by wikipedia in the future. This standard may solve many many problems and be more in the spirit of wikipedia, as it will be very simple to use/implement and the information would be useable by anyone and any program that wishes it to use. (In reply to comment #10) > Hi. Here's some links that might be useful to you: > http://www.mediawiki.org/wiki/Commit_access and > http://www.mediawiki.org/wiki/Manual:Coding_conventions > > Cheers. Thank's for the links! I'm currently cleaning up the code according to the standards, I hope of being able to put out a 1.0.1 version some time soon (will probably take a few weeks) with the code newly formatted and adapted to the current standards and wiki-interface as well as tested with the newest wikipedia versions and browsers. I will inform everybody here with a new post as soon as this is done. (In reply to comment #3) > From a quick browse through, it's using $_GET, $_SESSION directly, the > messages > are done in the wrong way. It doesn't follow our coding guidelines, has '?>' > at > the end of each file, uses old/deprecated setup methods > > And that's without me reviewing the JS As said above, I am currently adapting the code to the newest standards (if there's a not-direct way of accessing $_GET and $_SESSION directly I change the code to use the alternative). In contrast to the PHP Code, the JavaScript code is very complex, but also very good documented. I have already, by now, changed the code to only use one globaly assigned variable (in the 1.0 version it uses multiple). So since that's done, there shouldn't be much to do in the JavaScript code I think. It's pretty good tested with many browsers and I'm sure the new browsers will be able to work with it as good as the older ones did, but I'm of corse testing it anyway. (In reply to comment #5) > * Navigation seems a bit confusing; mostly I seem to accidentally scroll way > too far and get lost in -40,000 BC. :) Probably needs some overhauling on > ensuring that you don't wander away from the data. There's a little link between the two timelines that reads "show all", it ensures that the timeline zooms in to the first beginning and last ending event. So that all events are shown on the timeline as big as possible. It ensures that, if you have wandered off or zoomed in too much or lost yourself any other way, you can always click on "show all" and you're kind of 'on the start again'. (In reply to comment #7) > A single-purpose extension here for creating those event 'links' seems very > awkward and hard to maintain, in addition to simply being very confusing for > users (clicking on a link bumps the page around vertically with no explanation > if you're not at the top of the page, and if you are at the top of the page > the > view still is pretty unclear). In version 1.0.1 the timeline will be displayed at the bottom of the page, so it shouldn't jump around vertically. And now to the date-information-standard, which I think is something that comes pretty close to what Brion already wrote... (In reply to comment #7) > Being able to extract general date information so you can put *any temporal > event* into an interactive timeline, rather than just some handful that have > been manually annotated specifically for it, would make it much more valuable > and interesting. > > If something like that can be done, I'd probably recommend building a timeline > tool like this as a JavaScript gadget, as that'll be much easier to deploy for > opt-in usage. > > To make this something we'd really be excited about you'd also probably need > ways to save and share the built timelines; while looking at one just for fun > by yourself might be occasionally useful, saving one for yourself for your > ongoing research, or saving one into an article where it can be seen as a > whole, would be far more useful and allows building on each others' work. ... It would be called "Open Date Standard" (I already own the domain opendatestandard.org) and, as the name says, would be an open standard. Meaning that per definition, there is no fee or charge coming along with it's use and the definition must be freely accessible. Also, it will be useable with every program wished and will not affect the programs license (you can use the standard in a commercial program, a private or an open source, it doesn't matter). I'm currently also in the development of the license which I'm specially writing for this standard. The purpose of this standard would be 1) to define per XSD how the date would be displayed in XML and 2) to define per XSD how any calender can be defined in XML and with informatin regarding its conversion of any date in this calender to a date in another calender. To put it simple, the possible outcome would be this: 1) Any website, program, database or whatsoever (in this example we'll take one Wikipedia article) will send the date information along with its html (just like rss). One date entry may consinst for example of: Description (America), >From (1776 given in gregorian calender), Till (today) and is for example sent in a seperate file as xml information. 2) Any program, for example a FireFox-Extension, may recieve and read this xml data and because of the standard, is a) able to interpret the data and b) able to convert it in a date of another calender (like hebrew or arab) 3) The program may display or save the information in any calender and any form it likes. This ensures a) easy and free access to simple information b) programs now know how to interpretate this information in different ways c) programs can use this information in any way they want. By the way, by using the date information in the infoboxes and building an xml file for every article out of it we already have thousands of date-information ready for this. A little example? A teacher accesses the article of Napoleon on Wikipedia and saves the life-data with an FireFox-Extension in a file. He does the same with the start and end-dates of the frensh revolution and the founding dates of america. He goes into his class the next day and loads the data into some fancy program that can display those dates in a pretty way and shows the timeline of those events to his pupils... and hopefully they all make "wow" and have it a little bit easier (and with more fun) to learn history than we did ;) So... the standard would of course be totaly independend of wikipedia, and its coming anyway... but I think it would be very usefull to wikipedia! What do you think? greetings, Markus -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
