Not quite, but OpenSeadragon supports it so as soon as we have IIIF for
Commons files it'll be possible.
And it's also possible to use the Internet Archive's IIIF API.
@inductiveload, you have a prototype for this don't you?
On 23/11/21 4:31 am, Andrea Zanni wrote:
Hey everybody,
I stumbled upon this message by chance, but now I'm curious:
are you implementing IIIF on Wikisource?
That's very interesting!
Aubrey
On Mon, Nov 22, 2021 at 1:13 PM Ruthven <ruthven.wiki(a)gmail.com
<mailto:ruthven.wiki@gmail.com>> wrote:
Hi all, and thanks for the info.
I get from your messages that there are two major points to be solved:
1. A clear lack of communication (mass messages are often unread
or quickly read, because there is some abuse of the tool, and
what is important gets lost in the flood of messages). Probably
it's not the role of developers to communicate, but someone has to
do it.
2. A clear lack of management. There is a global lack of trust in
Mediawiki developers for the reason above, but also because
certain changes introduced more issues than they solved. I agree
with Sam: there is a need for product managers, who can also
communicate about important changes, but also check the
development and be sure that new changes can be safely deployed. I
mean: it's the basics of software development!
I don't think it's a matter of time if we focus on one feature at
a time, test it, test it again, do beta test, and then merge it.
We're not a software house: we do have time. I understand that
volunteers might not be happy in being constrained by a strict
workflow, but I also understand that work has to be done well or
not done at all.
Btw, I understand that there is beta.wikisource somewhere. Maybe
an invitation to the different projects to test the new features
there before the merge, would be a good occasion to involve more
people in quality control. (sorry if this has been done, and I've
missed it)
Cheers,
A.
*Ruthven*on Wikipedia
On Mon, 22 Nov 2021 at 04:45, Sam Wilson <sam(a)samwilson.id.au
<mailto:sam@samwilson.id.au>> wrote:
I think most Wikisource developers are likely to be on this
list. Of course, it's best to make sure there are Phabricator
tickets for every separate bug or feature request.
On 21/11/21 1:36 am, Ankry wrote:
Well, I was notified by techncally skilled users that the ned
OpenSeadragon library is much heavier and more memory
consuming than curreently used tools. So I can only hope that
its load into memory can be disabled if one needs so.
(may be critical while working on multiple pages at once)
However, I doubt if any technical comments from communities
expressed here will reach developers. And which wiki pages
would be more appropriate for such comments.
Ankry
W dniu 20.11.2021 o 14:33, Ruthven pisze:
Hi all,
as usual, I get surprised every time there are major
changes on the MediaWiki software that are deployed without
providing advance warning to the community.
Every time it's the same story: something stops working on
the project. A gadget, a toolbar or some personalised JS.
This time it was T288141 (see
https://phabricator.wikimedia.org/T288141
<https://phabricator.wikimedia.org/T288141>), that was
deployed in all the Wikisources (then rolled back because
WikiMedia computer scientists are the best) completely
disrupting redesigning the image side of the Page namespace.
This affected the toolbars (see
https://phabricator.wikimedia.org/T296033
<https://phabricator.wikimedia.org/T296033>) and several
gadgets around all the Wikisources.
I am not saying that MediaWiki software shouldn't be
improved: it's normal that we're trying to get all we can
from this outdated software. I am just asking that major
changes that affect all the Wikisources should be announced
in every single Village Pump waaay before deploying them on
the projects.
Is it possible, as a Usergroup, to do a little pressure to
be considered as a community and not as guinea pigs on which
to deploy new, partially-tested features?
Alex
*Ruthven*on Wikipedia
_______________________________________________
Wikisource-l mailing list --wikisource-l(a)lists.wikimedia.org
<mailto:wikisource-l@lists.wikimedia.org>
To unsubscribe send an email towikisource-l-leave(a)lists.wikimedia.org
<mailto:wikisource-l-leave@lists.wikimedia.org>
_______________________________________________
Wikisource-l mailing list --wikisource-l(a)lists.wikimedia.org
<mailto:wikisource-l@lists.wikimedia.org>
To unsubscribe send an email towikisource-l-leave(a)lists.wikimedia.org
<mailto:wikisource-l-leave@lists.wikimedia.org>
_______________________________________________
Wikisource-l mailing list -- wikisource-l(a)lists.wikimedia.org
<mailto:wikisource-l@lists.wikimedia.org>
To unsubscribe send an email to
wikisource-l-leave(a)lists.wikimedia.org
<mailto:wikisource-l-leave@lists.wikimedia.org>
_______________________________________________
Wikisource-l mailing list -- wikisource-l(a)lists.wikimedia.org
<mailto:wikisource-l@lists.wikimedia.org>
To unsubscribe send an email to
wikisource-l-leave(a)lists.wikimedia.org
<mailto:wikisource-l-leave@lists.wikimedia.org>
_______________________________________________
Wikisource-l mailing list -- wikisource-l(a)lists.wikimedia.org
To unsubscribe send an email to wikisource-l-leave(a)lists.wikimedia.org