In order to obtain current events from the Wikipedia in wiki markup, an application generally needs to take the following steps:
1. Construct the current date string in the form of "YYYY_MO_DA", e.g., "2009_April_1"
2. Perform GET by the URL for the given date string for viewing the page source, e.g,
http://en.wikipedia.org/w/index.php?title=Portal:Current_events/2009_April_…
3. Pick the content of the HTML <textarea> element.
Since not documented, i'm wondering whether the above is the expected way of accessing the current events in Wikipedia? Or is there a more elegant solution for the same task?
TIA,
Shriram
Andrew Gray wrote:
> 2009/3/3 David Gerard <dgerard at gmail.com>:
> > By Hakon Wium Lie of Opera:
> >
> > http://www.princexml.com/howcome/2009/wikipedia/infobox/
> >
> > What is the likelihood of making as much as possible CSS? How to make
> > infoboxes degrade gracefully for non-CSS browsers and IE users?
>
> Youch, that's messy in IE7. Lovely though it may be, that 30-50% of
> our audience would not be happy...
Right. I agree that graceful degradation for IE6/IE7 users is an
issue. The purpose of the case study was first and foremost to explore
how Wikipedia's markup can be simplified and improved when CSS 2.1 is
fully implemented -- like it is in Opera, Firefox, Safari and IE8. I
didn't even test in IE6/IE7.
I think it's possible -- with some careful crafting -- to make things
look ok, but not pixel-perfect in legacy browsers. In lynx, the
table-free version looks better than the original one, but IE6/IE7
users outnumber lynx by a some magnitudes.
I'll look into tweaking the style sheet to aim for graceful degradation.
However, I also think the web should not be hostage to IE6/IE7
forever. Some designers have declared war on IE6 for this reason:
http://blog.wired.com/business/2009/02/norwegian-websi.html
Cheers,
-h&kon
Håkon Wium Lie CTO °þe®ª
howcome(a)opera.com http://people.opera.com/howcome
I agree with the sentiment that flagged revisions would take care of this
additional issue as well.
Flagged revisions also allows people, like me, who are used to working
entirely online, to create drafts, then wander away for a while, then come back
and add more details, until you have a publishable version. This is the way I
frequently work. Flagged revs would allow that to be all in-project. Right
now, I sometimes have to create drafts on some white-board at some other
site, then copy and paste when I have a worked-up version. Which is needless
double-work in my opinion.
Will Johnson
**************Feeling the pinch at the grocery store? Make dinner for $10 or
less. (http://food.aol.com/frugal-feasts?ncid=emlcntusfood00000001)
<<In a message dated 4/2/2009 5:18:23 A.M. Pacific Daylight Time,
carcharothwp(a)googlemail.com writes:
Will, look at the example I provided earlier in this thread.
Established editors and admins were blindly reverting vandalism and
leaving an article in a state of previous vandalism. How do you begin
to address that problem?>>
You don't address it by allowing any admin who got their badge knowing next
to nothing about NOR (as many don't) do remove the right of established users
who have been in-project ten times longer than they. I will never, not
ever, agree to giving admins extra powers. They already have several powers they
should not have in my opinion. The idea behind admins, imho, was supposed
to be that they are helpful janitors clearning up messes, not theat they were
thought police enforcing the boundary line with clubs.
If we want to create new powers, then we need perhaps new categories of
user. For those users who do not want to be police, but are quite willing to
enhance the content of the project, we should create a parallel track, not a
subordinate one. No matter what anyone states, if a reviewer's right can be
removed at the whim (yes whim) of any admin, then reviewers are subordinate to
admins. They should not be.
Will Johnson
**************Feeling the pinch at the grocery store? Make dinner for $10 or
less. (http://food.aol.com/frugal-feasts?ncid=emlcntusfood00000001)
In a message dated 4/2/2009 1:20:14 PM Pacific Daylight Time,
doc.wikipedia(a)ntlworld.com writes:
> If reviewer right is wrongly removed - we'll have the internal problem
> of an upset editor (big deal? not - get over it!), however if it is
> granted to someone who misuses it then it breaches our quality control
> and can damage living people.
>>
---------------------
Your fallacy is trying to restrict "reviewer" to the BLP issue.
Imagine you are reviewing away at the Israeli-Palestinian conflict.
And you get caught up in a wheel war between conflicting admins.
Effectively, under the scenario that any admins can remove reviewer rights
you would have the situation that no non-admin reviewer could EVER review the
article.
I'm sure you see this. This is not a new thing. We sign on more admins to
take care of the backlogs, not to get into conflicts.
Giving them more conflict-creation powers is not a good thing, it's a bad
thing.
Those people who are to grant or remove the reviewer right, need to be at a
level *above* the "backlog cleanup crew", and "fight vandalism" people.
Because that level is too fraught with article-space-conflicts, and additional
content-effecting powers would just tend to create more of that, not less.
Will Johnson
**************
Feeling the pinch at the grocery store? Make dinner for $10 or
less. (http://food.aol.com/frugal-feasts?ncid=emlcntusfood00000001)
<<In a message dated 4/1/2009 9:45:06 A.M. Pacific Daylight Time,
arromdee(a)rahul.net writes:
(And WP:COI really does seem to say it's a conflict of interest for an
article about the Earth to be made by Earthlings. >>
If we really need the article to be made by people from other planets, I
have a few candidates I could offer.
Will Johnson
**************Feeling the pinch at the grocery store? Make dinner for $10 or
less. (http://food.aol.com/frugal-feasts?ncid=emlcntusfood00000001)
An out-of-memory condition crashed the database master for English
Wikipedia; we were down for about 25 minutes. All is restarted and
recovered now (thanks Domas!); our other sites were not affected.
http://techblog.wikimedia.org/2009/03/english-wikipedia-database-temporaril…
-- brion vibber (brion @ wikimedia.org)
CTO, Wikimedia Foundation
San Francisco
[spotted by Mathias Schindler]
http://encarta.msn.com/guide_page_FAQ/FAQ.html
Important Notice: MSN Encarta to be Discontinued
On October 31, 2009, MSN® Encarta® Web sites worldwide will be
discontinued, with the exception of Encarta Japan, which will be
discontinued on December 31, 2009. Additionally, Microsoft will cease
to sell Microsoft Student and Encarta Premium software products
worldwide by June 2009. We understand that Encarta users may have
questions regarding this announcement so we have prepared this list of
questions and answers below. Please keep reading if you would like
more information about these changes to Encarta.
- d.