Hi all, is there a way to export section of articles by the 'special:export' feature, please?
I.e., I would like to export the sections named ''Exit list'' from the articles 'Autobahn A(number)' from English wikipedia. (Of course I can manage to develop some kind of macro to do that, if this feature is not available). Anyway, the obvious attempt to export Autobahn A1#Exit list via the special:export page yields the entire page exported as a result. Many thanks, Claudi
--------------------------------- Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Claudi Meneghin wrote:
Hi all, is there a way to export section of articles by the 'special:export' feature, please?
Nope, sorry. Get the page and extract the bits you want.
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Brion Vibber wrote:
Claudi Meneghin wrote:
Hi all, is there a way to export section of articles by the 'special:export' feature, please?
Nope, sorry. Get the page and extract the bits you want.
Might there be a reason for this feature? Something about mobile devices perhaps?
Claudi Meneghin wrote:
Hi all, is there a way to export section of articles by the 'special:export' feature, please?
Special:Export doesn't allow section-exporting. Plus, MediaWiki doesn't choose sections by name, but for number.
You can browse to teh article, click the section edit and copy&paste. Or you could make a script to strip everything from the article but the Exit list section.
Perhaps the "section=" parameter could work for viewing as well as editing: http://en.wikipedia.org/w/index.php?title=Bundesautobahn_1&action=view%C...
With section preview on you effectively can view just one section, but you get the edit box as well.
Steve
On 2/14/07, Platonides Platonides@gmail.com wrote:
Claudi Meneghin wrote:
Hi all, is there a way to export section of articles by the 'special:export' feature, please?
Special:Export doesn't allow section-exporting. Plus, MediaWiki doesn't choose sections by name, but for number.
You can browse to teh article, click the section edit and copy&paste. Or you could make a script to strip everything from the article but the Exit list section.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 2/13/07, Steve Bennett stevagewp@gmail.com wrote:
Perhaps the "section=" parameter could work for viewing as well as editing: http://en.wikipedia.org/w/index.php?title=Bundesautobahn_1&action=view%C...
With section preview on you effectively can view just one section, but you get the edit box as well.
Interesting idea. We could have an option to make the TOC be real links, too, not just anchors.
On 2/14/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Interesting idea. We could have an option to make the TOC be real links, too, not just anchors.
Yeah, and as an option, a [view] link next to the [edit] link.
Steve
On 2/14/07, Steve Bennett stevagewp@gmail.com wrote:
Yeah, and as an option, a [view] link next to the [edit] link.
Or perhaps [print], since that would probably be the use for it.
Steve
This timely discussion fits in with my explorations last night for adding more structure awareness to mediawiki. Wiktionaries in particular have standardized formats where headings and subheadings with standard names provide structure for the data.
In the short term we need to wrap each section and subsection in a div with a class name which reflects the heading. In the long term we need to provide accessor functions that can manipulate sections in a way similar to the DOM. See bug 6104.
Andrew Dunbar (hippietrail)
On 2/14/07, Steve Bennett stevagewp@gmail.com wrote:
On 2/14/07, Steve Bennett stevagewp@gmail.com wrote:
Yeah, and as an option, a [view] link next to the [edit] link.
Or perhaps [print], since that would probably be the use for it.
Steve
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 2/14/07, Andrew Dunbar hippytrail@gmail.com wrote:
In the short term we need to wrap each section and subsection in a div with a class name which reflects the heading. In the long term we need to provide accessor functions that can manipulate sections in a way similar to the DOM. See bug 6104.
Yeah, I understand that we can now transclude sections of other pages. But if it's controlled by section heading or section number, that's a method very prone to breaking. Also, it would be good to be able to demarcate sections of a page *other* than through headings, if possible.
Do you have any proposed syntax or other solution?
Steve
On Wed, Feb 14, 2007 at 02:55:20PM +1100, Steve Bennett wrote:
On 2/14/07, Andrew Dunbar hippytrail@gmail.com wrote:
In the short term we need to wrap each section and subsection in a div with a class name which reflects the heading. In the long term we need to provide accessor functions that can manipulate sections in a way similar to the DOM. See bug 6104.
Yeah, I understand that we can now transclude sections of other pages. But if it's controlled by section heading or section number, that's a method very prone to breaking. Also, it would be good to be able to demarcate sections of a page *other* than through headings, if possible.
Do you have any proposed syntax or other solution?
Well, my snap reaction is 'microformats'.
If you're going to try to make picking a section out of a different page reliable, then neither section number nor name seems like a good choice of (sub-)address; one is an accident, and the other intended for humans.
I think that there should be some way (and perhaps this is as easy as puting an "<a href="thisisatag"> link in after the section header.
Isn't there some pipe-y syntax that already does something akin to this and tracks the section header?
Cheers, -- jra
On 2/14/07, Jay R. Ashworth jra@baylink.com wrote:
Well, my snap reaction is 'microformats'.
Say what?
I think that there should be some way (and perhaps this is as easy as puting an "<a href="thisisatag"> link in after the section header.
Isn't there some pipe-y syntax that already does something akin to this and tracks the section header?
Yeah, I was wondering that. Something like this might work: ==List of highways|List==
Where "List" is a code. Alternatively, and imho more readably: ==List of highways== {{SECTION|List}}
Steve
Wiktionary's case is a bit easier because we don't need to transclude sections but merely make them accessible to MediaWiki extensions written in PHP.
For instance most users don't care about translations so that section would not be displayed by default unless enabled in preferences.
A good incremental design path might be 1: wrap sections/subsections in DIVs 2: provide section/subsection APIs for extensions. 3: make sections transcludable.
Andrew Dunbar (hippietrail)
On 2/14/07, Steve Bennett stevagewp@gmail.com wrote:
On 2/14/07, Jay R. Ashworth jra@baylink.com wrote:
Well, my snap reaction is 'microformats'.
Say what?
I think that there should be some way (and perhaps this is as easy as puting an "<a href="thisisatag"> link in after the section header.
Isn't there some pipe-y syntax that already does something akin to this and tracks the section header?
Yeah, I was wondering that. Something like this might work: ==List of highways|List==
Where "List" is a code. Alternatively, and imho more readably: ==List of highways== {{SECTION|List}}
Steve
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
If we want sections to be transcludable, we need to address them by name and not by number, because adding a header might cause an other section to be included.
Bryan
On 2/14/07, Andrew Dunbar hippytrail@gmail.com wrote:
Wiktionary's case is a bit easier because we don't need to transclude sections but merely make them accessible to MediaWiki extensions written in PHP.
For instance most users don't care about translations so that section would not be displayed by default unless enabled in preferences.
A good incremental design path might be 1: wrap sections/subsections in DIVs 2: provide section/subsection APIs for extensions. 3: make sections transcludable.
Andrew Dunbar (hippietrail)
On 2/14/07, Steve Bennett stevagewp@gmail.com wrote:
On 2/14/07, Jay R. Ashworth jra@baylink.com wrote:
Well, my snap reaction is 'microformats'.
Say what?
I think that there should be some way (and perhaps this is as easy as puting an "<a href="thisisatag"> link in after the section header.
Isn't there some pipe-y syntax that already does something akin to this and tracks the section header?
Yeah, I was wondering that. Something like this might work: ==List of highways|List==
Where "List" is a code. Alternatively, and imho more readably: ==List of highways== {{SECTION|List}}
Steve
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- http://linguaphile.sf.net
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
In the labeled section transclusion extension (written for wikisource, but not installed yet) sections are transcluded by name, either using the heading, or a special <section> marker; transclusion by heading is optional, since it could be more more prone to breakage (i.e. renaming a header), and it's less obvious exactly what needs to be included.
Wictionary could probably leverage this type of mechanism, similarly to the way the DPL extension does, by calling LST functions to get the sections.
On Wed, 14 Feb 2007 12:09:29 +0100, Bryan Tong Minh wrote:
If we want sections to be transcludable, we need to address them by name and not by number, because adding a header might cause an other section to be included.
Bryan
On 2/14/07, Andrew Dunbar hippytrail@gmail.com wrote:
Wiktionary's case is a bit easier because we don't need to transclude sections but merely make them accessible to MediaWiki extensions written in PHP.
For instance most users don't care about translations so that section would not be displayed by default unless enabled in preferences.
A good incremental design path might be 1: wrap sections/subsections in DIVs 2: provide section/subsection APIs for extensions. 3: make sections transcludable.
Andrew Dunbar (hippietrail)
On 2/14/07, Steve Bennett stevagewp@gmail.com wrote:
On 2/14/07, Jay R. Ashworth jra@baylink.com wrote:
Well, my snap reaction is 'microformats'.
Say what?
I think that there should be some way (and perhaps this is as easy as puting an "<a href="thisisatag"> link in after the section header.
Isn't there some pipe-y syntax that already does something akin to this and tracks the section header?
Yeah, I was wondering that. Something like this might work: ==List of highways|List==
Where "List" is a code. Alternatively, and imho more readably: ==List of highways== {{SECTION|List}}
Steve
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- http://linguaphile.sf.net
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Feb 14, 2007 at 03:20:19PM +1100, Steve Bennett wrote:
On 2/14/07, Jay R. Ashworth jra@baylink.com wrote:
Well, my snap reaction is 'microformats'.
Say what?
There was a fairly extensive discussion on this list a couple weeks ago -- which I thought you had participated in -- about microformats (I think the buzzword was) which amounted to "custom-made attributed to HTML tags which would be usable for semantic extraction, but ignored by browsers".
Or at least that was what *I* got from the discussion. ;-)
This topic, and the approach you and I forsee, is sort of an offshoot thereof...
Cheers, -- jra
On 2/16/07, Jay R. Ashworth jra@baylink.com wrote:
There was a fairly extensive discussion on this list a couple weeks ago -- which I thought you had participated in -- about microformats (I think the buzzword was) which amounted to "custom-made attributed to HTML tags which would be usable for semantic extraction, but ignored by browsers".
I'm sure I've never heard that term before, but fortunately [[Microformats]] got me up to speed. (Is there anything Wikipedia can't do :))
This topic, and the approach you and I forsee, is sort of an offshoot thereof...
I guess. What would the syntax look like to the user?
Steve
On Fri, Feb 16, 2007 at 10:18:14AM +1100, Steve Bennett wrote:
On 2/16/07, Jay R. Ashworth jra@baylink.com wrote:
There was a fairly extensive discussion on this list a couple weeks ago -- which I thought you had participated in -- about microformats (I think the buzzword was) which amounted to "custom-made attributed to HTML tags which would be usable for semantic extraction, but ignored by browsers".
I'm sure I've never heard that term before, but fortunately [[Microformats]] got me up to speed. (Is there anything Wikipedia can't do :))
This topic, and the approach you and I forsee, is sort of an offshoot thereof...
I guess. What would the syntax look like to the user?
Well, one suggested solution was piping the
==section header tag|secthead==
but while I understand why that is most intiutive to people who *get* Wikipedia, I suspect it's a bit too breakable when confronted with people who don't--and there are a lot more of them. So I like a template or parser function that takes an argument and expands to the appropriate hidden markup to support the pointer, myself.
Cheers, -- jra
On Saturday 17 February 2007 21:04, Jay R. Ashworth wrote:
On Fri, Feb 16, 2007 at 10:18:14AM +1100, Steve Bennett wrote:
On 2/16/07, Jay R. Ashworth jra@baylink.com wrote:
There was a fairly extensive discussion on this list a couple weeks ago -- which I thought you had participated in -- about microformats (I think the buzzword was) which amounted to "custom-made attributed to HTML tags which would be usable for semantic extraction, but ignored by browsers".
I'm sure I've never heard that term before, but fortunately [[Microformats]] got me up to speed. (Is there anything Wikipedia can't do :))
This topic, and the approach you and I forsee, is sort of an offshoot thereof...
I guess. What would the syntax look like to the user?
Well, one suggested solution was piping the
==section header tag|secthead==
but while I understand why that is most intiutive to people who *get* Wikipedia, I suspect it's a bit too breakable when confronted with people who don't--and there are a lot more of them. So I like a template or parser function that takes an argument and expands to the appropriate hidden markup to support the pointer, myself.
Semantic MediaWiki in parts is very similar to what microformats try to achieve. It collects semantic data and offers it in machine-readable formats. The difference is that it also can work on the data within the wiki (e.g. you can search for things). One could adjust Semantic MediaWiki to support microformat-like applications. Now I don't know which microformat you have in mind -- Semantic MediaWiki is not the solution for everything; but is has a lot of existing infrastructure that was built for storing and processing such structured data. So maybe extending Semantic MediaWiki is easier than building another parser extension for microformats.
In general, microformats are application-specific mini-markups, that were tailored to simplify markup for people who write XHTML. Microformats are intended to be easy to write (for people used to writing XHTML), but they are not easy to parse. Extracting microformat data from XHTML may require substantial effort (at least that's what I heard from microformat people at the W3C Technical Plenary last year). Now if you create a wiki markup (Semantic MediaWiki has one, but you can invent another one if you need), just to re-embed the already extracted information into XHTML, this seems to be unnecessarily complicated. Since you already have the information, you can easily provide it in a separate block of data -- both XML and RDF based formats are available for many typical microformat applications.
There are many ways to attach metadata to HTML. flickr for instance exports RDF metadata by directly embedding it into XHTML pages in a sort of customised way. The RDFa effort is about to standardise a clean solution for this. Semantic MediaWiki in turn puts the RDF on another URL which is linked to the HTML-document through the header (this is fully XHTML conformant and it scales to larger amounts of data); tools like Firefox' Piggybank extension will find the data and can import it.
Microformats are still a very good starting point: they have identified common applications and provide sets of important property definitions for each. This is certainly something to draw from. I just would not implement a wiki markup, XHMTL encoding, and custom handling for each such format.
Btw. what tool that supports microformats do you have in mind? Maybe this tool supports further input formats that have been invented for similar applications.
Cheers,
Markus
On 2/18/07, Jay R. Ashworth jra@baylink.com wrote:
Well, one suggested solution was piping the
==section header tag|secthead==
One obvious weakness with this is we don't have a way of terminating sections. Granted, that's a problem in general with sections of this sort, but it crops up here. Perhaps we would allow something like this as a terminator: ==|==
(pretty isn't it :))
but while I understand why that is most intiutive to people who *get* Wikipedia, I suspect it's a bit too breakable when confronted with people who don't--and there are a lot more of them. So I like a template or parser function that takes an argument and expands to the appropriate hidden markup to support the pointer, myself.
So something like this? {{section header tag|secthead}}
Or do you mean: ==section header tag== {{sectionmagicword|secthead}}
Steve
On Tue, Feb 20, 2007 at 12:49:16AM +1100, Steve Bennett wrote:
On 2/18/07, Jay R. Ashworth jra@baylink.com wrote:
Well, one suggested solution was piping the
==section header tag|secthead==
One obvious weakness with this is we don't have a way of terminating sections. Granted, that's a problem in general with sections of this sort, but it crops up here. Perhaps we would allow something like this as a terminator: ==|==
(pretty isn't it :))
Sections terminate at either the next section header marker, or the next one at that level -- doesn't matter which, as long as it's declared at release time. Both have advantages.
but while I understand why that is most intiutive to people who *get* Wikipedia, I suspect it's a bit too breakable when confronted with people who don't--and there are a lot more of them. So I like a template or parser function that takes an argument and expands to the appropriate hidden markup to support the pointer, myself.
So something like this? {{section header tag|secthead}}
Or do you mean: ==section header tag== {{sectionmagicword|secthead}}
The latter, yes. If you're tagging something for remote retrieval, you want the tag decoupled from both the accidental section number, and the human changeable section header text.
Cheers, -- jra
On 2/22/07, Jay R. Ashworth jra@baylink.com wrote:
Or do you mean: ==section header tag== {{sectionmagicword|secthead}}
The latter, yes. If you're tagging something for remote retrieval, you want the tag decoupled from both the accidental section number, and the human changeable section header text.
If we're doing that, we might as well have start/stop tags, and totally decouple it from the idea of wiki ==Headings==. It would seem useful both to be able to transclude several sections, and less than a whole section.
Steve
wikitech-l@lists.wikimedia.org