Wikimedia Bugzilla is closed!

(In reply to comment #0)
> The api should add a parameter allowing the user to output several
> pages in MediaWiki's Special:Export format.
> 
It already has one.

> (Currently api.php mentions an export option, but that is a different
> export format.)
> 
No, that's the same format if you use &exportnowrap.


> Perhaps add a parameter to include/remove the Header, and just emit
> the <item>s.
> 
That would be a different format than Special:Export's, and I don't see how it would be useful.

> Using the api, the user could then have a very powerful tool to export
> many more different slices of the wiki than the current maintenance
> scripts or Special:Export allows!
> 
That's already there.

> And do add a note for users to see on Special:Export that they can
> also use the api to export a great many different slices.
> 
That's something for the TranslateWiki folks to worry about.

Closing as WORKSFORME as this bug doesn't seem to request any API features that aren't already there; if it does, please REOPEN and specify your feature request more clearly.

OK, at
  exportnowrap   - Return the export XML without wrapping it in an XML result
please add "same format as [[Special:Export]]".
else one might never know the connection.

I'll now change this bug to
> add a note for users to see on Special:Export that they can
> also use the api to export a great many different slices.

Changed the exportnowrap description in r48312. Not so sure about tweaking the default Special:Export to mention the API. We don't suggest using the API elsewhere in the UI, do we?

Bug as filed is fixed, closing. Changing the interface messages on Special:Export would be a TranslateWiki issue.

OK, adding a patch to start internationalization.

I'm not sure if how I link is the best way etc.

And maybe this message shouldn't even appear if API is disabled via LocalSettings, etc.

So feel free to reclose.

Created attachment 5921 [details]
mention api in special:export

Please create a new patch, adding a message and necessary code changes to only display the alternative if the wiki is actually configured to allow this.

Changes component to import/export, as this is not i18n/L10n, but rather documentation on import/export.

(In reply to comment #7)
> Please create a new patch, adding a message and necessary code changes to only
> display the alternative if the wiki is actually configured to allow this.
> 

The only check should be seeing if the API is enabled, doesn't require any extra config.

I'm still not sure if it's a good idea. As I said earlier: we don't suggest using the API elsewhere in the UI (the only mentions of the API in the core messages are in relation to the rights- and friends messages). If the UI needs improvement, file bugs for specific improvements there...the API isn't designed for users, so don't tell users to use it.

> the API isn't designed for users
Perhaps add warnings to that effect on api.php and http://www.mediawiki.org/wiki/API
otherwise folks will certainly spread the gospel to their users.

Hmmm, a user downloading XML dumps is no simple user.
So perhaps do if(api enabled){
print a message duplicated from
'shareduploadwiki' => 'Please see the $1 for further information.',
where $1 would be "this site's api.php, and http://www.mediawiki.org/wiki/API"
or just the former, as it links to the latter anyway.
}

(In reply to comment #9)
> > the API isn't designed for users
> Perhaps add warnings to that effect on api.php and
> http://www.mediawiki.org/wiki/API
> otherwise folks will certainly spread the gospel to their users.
> 

That's not our fault. API stands for APPLICATION programming interface and it is not designed for human use. If humans want to pretend to be bots, that's fine but we are in no way obligated to humour them. Marking WONTFIX per this and comment 8.