context
-------
i’m working on a mediawiki extension,
http://www.mediawiki.org/wiki/Extension:GWToolset, which has as one of its
goals, the ability to upload media files to a wiki. the extension, among
other tasks, will process an XML file that has a list of urls to media
files and upload those media files to the wiki along with metadata
contained within the XML file. our ideal goal is to have this extension run
on http://commons.wikimedia.org/ <onhttp://commons.wikimedia.org/>.
background
----------
h
ttp://commons.wikimedia.org/wiki/Commons:GLAMToolset_project/Request_for_Co…<http://commons.wikimedia.org/wiki/Commons:GLAMToolset_project/Request_for_C…>
Metadata Set Repo
-----------------
one of the goals of the project is to store Metadata Sets, such as XML
under some type of version control. those Metadata Sets need to be
accessible so that the extension can grab the content from it and process
it. processing involves iterating over the entire Metadata Set and creating
Jobs for the Job Queue which will upload each individual media file and
metadata into a media file page using a Mediawiki template format, such as
Artwork.
some initial requirements
• File sizes
• can range from a few kilobytes to several megabytes.
• max file-size is 100mb.
• XML Schema - not required.
• XML DTD - not required.
• When metadata is in XML format, each record must consist of a single
parent with many child
• XML attribute lang= is the only one currently used and without user
interaction
• There is no need to display the Metadata sets in the wiki.
• There is no need to edit the Metadata sets in the wiki.
we initially developed the extension to store the files in the File:
namespace, but we were told by the Foundation that we should use
ContentHandler instead. unfortunately there is an issue with storing
content > 1mb in the db so we need to find another solution.
1. any suggestions?
Mapping
-------
a mapping is a json that maps a metadata set to a mediawiki template. we’re
currently storing those as Content in the namespace GWToolset. an entry
might be in GWToolset:Metadata_Mappings/Dan-nl/Rijkmuseum.
1. does that namespace make sense?
a. if not, what namespace would you recommend?
2. does this concept make sense?
a. if not, what would you recommend?
Maintaining Original Metadata Snippet & Mapping
-----------------------------------------------
another goal is to link or somehow connect the original metadata used to
create the mediafile:
• metadata set
• metadata snippet
• metadata mapping
the current thought is to insert these items as comments within the wiki
text of the media file page
1. does that make sense?
a. if not, what would you recommend doing?
2. is there a better way to do this?
mediawiki template parameters
-----------------------------
the application needs to know what mediawiki template parameters exist and
are available to use for mapping media file metadata to the mediawiki
templates. for the moment we are hard-coding these parameters in a db table
and sometimes in the code. this is not ideal. i have briefly seen
TemplateData, but haven’t had enough time to see if it would address our
needs.
1. is there a way to programatically discover the available parameters for
a mediawiki template?
thanks in advance for your help!
dan
> From: Jay Ashworth <jra(a)baylink.com>
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Subject: Re: [Wikitech-l] editsection styling
>
> Therefore, for this category of separator, I think pipes would be less
> jarring to readers -- at least English readers.
> From: Steven Walling <steven.walling(a)gmail.com>
>
> Jay's previous answer is correct I think. When choosing between pipes and
> commas, the former are better for clear separation between equal elements.
> However, the honest truth is that using punctuation to call out and
> separate interactive elements like this is a pretty retrograde UI pattern.
>
> Images or symbols plus words are together more easily memorable than words
> alone. If you are in a situation where you let users interact with a LaTeX
> document using a variety of methods, the ideal design might be one where
> you give each type (log, pdf, dvi) a small, simple, and easily
> distinguishable icon. Adding things like appropriate styles on hover, to
> denote when a user is about to select an element, also might be helpful.
>
> Ultimately I think we want to be shooting for a world where we can just use
> whitespace, icons, and other less busy-looking methods to denote section
> edit links,[1] rather than using punctuation.
>
> Steven
>
> 1. https://usability.wikimedia.org/wiki/Acai_Designs#Section_Edit_Links
Thanks both - this is very useful. Steven - do you have any screenshots
showing how you would prefer to represent multiple actions such as
"Edit" and "Edit Source"?
LW
I just noticed that the editsection links, now with both the visual and
source editor links, use a pipe character (|) to separate the two. Is
this generally the desired way to separate multiple links in a bracketed
section like this, in MW? Is there a policy?
I ask because I've been producing editsection-like links for a long time
in our extension project, with commas in between - for example a LaTeX
document will come with a list of links like "[log, pdf, dvi]". Maybe I
should switch to using pipes instead of commas.
Sorry in advance for such a bikeshed-friendly question :P ...
Lee Worden
McMaster U., UCB, SF Art Institute
WorkingWiki
I have a bot editing script that started having trouble logging
in to the English Wikipedia a few days ago. I think what's
happening is that the login process started using Javascript in a
way it didn't before, and is detecting that my script doesn't do
Javascript (which it doesn't), and throwing a second, fallback,
non-Javascript-using login page at the point where the script is
expecting to have already logged in.
So the question is, if this is the case, is there a way to force
the use of the non-Javascript login page from the beginning?
Or if this is not the case, is there some other recent change
that might have affected the flow?
(And, in case you're wondering, no, the script does not use the
API, but yes, I know about it, and this may be the circumstance
that goads me into actually using it.)