Brion,
thanks for response.
> Can you go into a little more detail on what an applet viewer might be used
> for?
The goal is to provide "inexperienced" users functions adaequate to
"old" LizardTech, now Celartem viewer add-on like zooming, page
scrolling and so on for a use in connection with our mini-DigiBib
(transkription of historical/genealogical handwritings and so on).
I agree, for simply viewing a page JPG conversion is often sufficient.
But bad scanned sources should be at least simple zoomable.
This - without additional manual installation of some add-on by this
mentioned user. JRE is installed in many cases, a transparent applet
would be good.
I understand (may be wrong) that the LizardTech add-on downloads and
shows only needed page(s) at once from a given remote DJVU file too -
why a applet couldn´t do so?
Concerning your security headache I think it is more comprehensible for
JavaScript (sandboxes) then for Java, and MediaWiki is "swimming" in
JavaScript. But ultimate decision makes the user.
Uwe (Baumbach)
U.Baumbach(a)web.de
--
Interwiki::getURL() accepts an argument, the string to replace $1 with.
However it doesn't urlencode it so $interwiki->getURL( 'A&B' ); can
return http://somewiki.com/index.php?title=A&B, so the outside caller is
required to do the urlencoding instead of the getURL where it should be
done (especially since getURL is the one that better understands the
context that $1 is in).
Scanning all of trunk and the extensions folder, it doesn't seam like
ANY part of core or any extensions make use of Interwiki::getURL with
the argument. If any use it they omit the argument and work like
Title::getFullURL which itself urlencodes data and does the substitution
of $1 on it's own outside of the Interwiki class.
Anyone have an objection to me changing the code so that
Interwiki::getURL properly urlencodes it's input and accepts normal text
instead of text required to be pre-urlencoded?
Pros:
- Saner api
- In the future we have the option of deciding to use different
urlencoding calls depending on if $1 is located in the path portion of
the url or the query portion of the url if it makes sense (like if we
ever get [[google:foo bar]] fixed we can use + instead of %20).
Cons:
- If someone later tries to use Interwiki::getURL inside an extension
the argument behavior will be different between versions before 1.19 and
1.19 and after. ie: They'll have to version test for 1.19 and if older
add a wfUrlencode call themselves.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Hi there.
I've made some modifications to MediaWiki 1.17.0 that others might be
interested in. I'd be flattered if some or all of them made it into the
official MediaWiki release.
Firstly, I've added links to the W3C HTML validation service hosted by
MIT. These show up as 'W3C HTML 5.0' icons next to the 'Powered by
MediaWiki' icon at the bottom of the page, and link the user to the HTML
validation service. I've found having this feature invaluable in helping
me to get my wiki text that includes HTML valid. Unfortunately I've had
to disable some features of MediaWiki in order for the validation
service to pass the generated HTML. You can read about how I modified
MediaWiki for W3C HTML validation at:
http://www.progclub.org/wiki/Pcwiki#W3C_validation_icon
Secondly, and more importantly I feel, I've added extended links to the
'section edit' links section. In addition to showing an 'edit' link, I
include a 'link' link, and a 'top' link. 'top' just links to #top,
nothing remarkable there. 'link' provides a link to the canonical URL
for that section. My web-site is available via several domain names,
www.progclub.org, progclub.org, progclub.info, etc. I have nominated
'www.progclub.org' as the 'canonical' domain name to be used when
publishing links, and nominated 'http' (rather than 'https') as the
'canonical' scheme. In order to support canonical section links I had to
make a few changes to the settings files, and update the linker, etc.,
as explained at:
http://www.progclub.org/wiki/Pcwiki#Extended_edit_links
Anyway, that's it. Thought some of you might like to know. If you like
the ideas but don't like the implementation, then please feel free to
BYO implementation. Mine's a little bit less than perfect owing to no
i18n support and me not knowing the best file to put my functions in.
So, I'd be happy if someone else gave my code a spruce up.
Thanks!
John.
Is it possible let MediaWiki hint the browser about the filename and
change the content type?
I have a wikipage, e.g., "Buss-Durkee Hostility Inventory". If I save
this page from the browser "Buss-Durkee_Hostility_Inventory.html" is
suggested as the filename, - which is fine.
I have another wikipage called "Bipolar Disorder Neuroimaging Database -
Amygdala.csv". When I download this page (from a template-constructed
link) with "/w/index.php?action=raw&title=" I get the filename suggested
as "index.php". I would like to have the filename as "Bipolar Disorder
Neuroimaging Database - Amygdala.csv" and also manipulate the content
type, e.g., to "Content-type: text/csv; charset=utf-8".
Is that possible?
My only idea would be to write a cgi-script that fetches the wikipage
with csv information and forwards it to the user while controlling the
content-type.
/Finn
--
Finn Årup Nielsen, DTU Informatics
http://www.imm.dtu.dk/~fn/ +45 45 25 39 21.
What: IRC Bug Triage
Where: #wikimedia-dev on freenode
Use http://webchat.freenode.net/ if you don't have an IRC
client.
When: 23:00 UTC (7PM EDT, 4PM EDT)
In just a few hours, I'll be doing the bug triage on IRC.
I plan to cover the 1.18 blockers as well as some current problems seen
on Wikipedia.
You're welcome to join us and provide your input.
Thanks,
Mark
Hi. I'm working on Extension:SwiftMedia, and I've got it into pretty decent shape. No known bugs (last bug was a coding bug; bug prior was a design bug). Since the plan is to switch Wikipedia over to this media storage system, we're trying to be as conservative and not-break-it as possible. If you are in the habit of manipulating files on your MediaWiki, or on Wikipedia itself, could you take a few minutes to document your particular combination of operations? Obviously, we've got test cases for "upload a file", "delete a file", "upload another file", "revert an older file". Those are the simple things to test. We're looking for your "idioms" or "use cases", where you do things we don't expect.
Your help is greatly appreciated. Document them here:
http://www.mediawiki.org/wiki/Extension:SwiftMedia#Use_Cases
This is a public request. Please repost it anywhere you think appropriate.
Thanks,
-russ
Is it possible to get a list of licenses for all the images on
wikipedia programmatically? Just the licenses, and a count of how many
images have which particular license.
Greetings all,
I got a couple of reports that it was a bit confusing to track where
we were with the MobileFrontend testing so I updated our deployment
page. Hopefully its easier now to understand what the Ruby gateway is
still doing vs mobile frontend.
http://www.mediawiki.org/wiki/MobileFrontend/Deployment#Status
Let me know if you have any questions.
--tomasz
If you'd like to improve MediaWiki's support for PostgreSQL, consider
submitting a talk about it to PG Day:
http://pgday.consistentstate.com/node/5
PG-Day Denver 2011 will be held on Friday, October 21st, 2011 at the
Auraria Campus near downtown Denver, Colorado, USA. PG-Day Denver will
include talks that will benefit PostgreSQL users, database
administrators, developers, and executives. The call for papers is open
till August 31, but it's better to submit earlier.
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Due to my inability to support HeaderTabs and other extensions that were
created by/for Semantic Communities LLC, I discontinued the mailing list
that was used for those extensions and instructed users to ask their
questions here.
Hope Yaron and others can continue helping those users out here as they
already do.
Thank you,
Sergey
--
Sergey Chernyshev
http://www.sergeychernyshev.com/http://www.meetup.com/Web-Performance-NY/http://www.showslow.com/