Scripto is an alternative to the ProofreadPage extension used
by Wikisource. It is based on Mediawiki but also on OpenLayers,
the software used to zoom and pan in OpenStreetMap.
The only website I have seen that uses Scripto is the U.K.
War Department papers, and in many ways it is more clumsy
than ProofreadPage. But there might be a few ideas that could
be worth picking up. Take a look.
The software is described at http://scripto.org/
As for reference installations, they mention
http://wardepartmentpapers.org/transcribe.php
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
They are enabling an alpha-version of the Visual Editor
in en.wikipedia.
This is really a huge thing: the Visual Editor could be paramount for
wikisource,
(because we have a lot of formatting and typography).
With a BIG problem though: when I asked the developers about
Visual Editor and Proofread Extension, they told me that it would not work.
The PR extensions works as an "hack", and can't embed the VisualEditor
right away.
It needs a lot of work, from what I understood.
I think it would be very important for us as a community to coordinate and
lobby a bit to have
our VE within the PR pages...
Aubrey
---------- Forwarded message ----------
From: James Forrester <jforrester(a)wikimedia.org>
Date: Wed, Dec 12, 2012 at 4:30 AM
Subject: [Wikimedia-l] Alpha version of the VisualEditor now available on
the English Wikipedia
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>,
wikimedia-l(a)lists.wikimedia.org
TL;DR: Today we are launching an alpha, opt-in version of the
VisualEditor[0] to the English Wikipedia. This will let editors create
and modify real articles visually, using a new system where the
articles they edit will look the same as when you read them, and their
changes show up as they type enter them — like writing a document in a
word processor. Please let us know what you think[1].
Why launch now?
We want our community of existing editors to get an idea of what the
VisualEditor will look like in the “real world” and start to give us
feedback about how well it integrates with how they edit right now,
and their thoughts on what aspects are the priorities in the coming
months.
The editor is at an early stage and is still missing significant
functions, which we will address in the coming months. Because of
this, we are mostly looking for feedback from experienced editors at
this point, because the editor is insufficient to really give them a
proper experience of editing. We don’t want to promise an easier
editing experience to new editors before it is ready.
As we develop improvements, they will be pushed every fortnight to the
wikis, allowing you to give us feedback[1] as we go and tell us what
next you want us to work on.
How can I try it out?
The VisualEditor is now available to all logged-in accounts on the
English Wikipedia as a new preference, switched off by default. If you
go to your “Preferences” screen and click into the “Editing” section,
it will have as an option labelled “Enable VisualEditor”).
Once enabled, for each article you can edit, you will get a second
editor tab labelled “VisualEditor” next to the “Edit” tab. If you
click this, after a little pause you will enter the VisualEditor. From
here, you can play around, edit and save real articles and get an idea
of what it will be like when complete.
At this early stage in our development, we recommend that after saving
any edits, you check whether they broke anything. All edits made with
the VisualEditor will show up in articles’ history tabs with a
“VisualEditor” tag next to them, so you can track what is happening.
Things to note
Slow to load - It will take some time for long complex pages to load
into the VisualEditor, and particularly-big ones may timeout after 60
seconds. This is because pages have to be loaded through Parsoid which
is also in its early stages, and is not yet optimised for deployment
and is currently uncached. In the future (a) Parsoid itself will be
much faster, (b) Parsoid will not depend on as many slow API calls,
and (c) it will be cached.
Odd-looking - we currently struggle with making the HTML we produce
look like you are used to seeing, so styling and so on may look a
little (or even very) odd. This hasn't been our priority to date, as
our focus has been on making sure we don't disrupt articles with the
VisualEditor by altering the wikitext (correct "round-tripping").
No editing references or templates - Blocks of content that we cannot
yet handle are uneditable; this is mostly references and templates
like infoboxes. Instead, when you mouse over them, they will be
hatched out and a tooltip will inform you that they have to be edited
via wikitext for now. You can select these items and delete them
entirely, however there is not yet a way to add ones in or edit them
currently (this will be a core piece of work post-December).
Incomplete editing - Some elements of "complex" formatting will
display and let you edit their contents, but not let users edit their
structure or add new entries - such as tables or definition lists.
This area of work will also be one of our priorities post-December.
No categories - Articles' "meta" items will not appear at all -
categories, langlinks, magic words etc.; these are preserved (so
editing won't disrupt them), but they not yet editable. Another area
for work post-December - our current plan is that they will be edited
through a "metadata flyout", with auto-suggestions and so on.
Poor browser support - Right now, we have only got VisualEditor to
work in the most modern versions of Firefox, Chrome and Safari. We
will find a way to support (at least) Internet Explorer post-December,
but it's going to be a significant piece of work and we have failed to
get it ready for now.
Articles and User pages only - The VisualEditor will only be enabled
for the article and user namespaces (so you can make changes in a
personal sandbox), and will not work with talk pages, templates,
categories, etc.. In time, we will build out the kinds of specialised
editing tools needed for non-articles, but our focus has been on
articles.
Final point
This is not the final form of the VisualEditor in lots of different
ways. We know of a number of bugs, and we expect you to find more. We
do not recommend people trying to use the VisualEditor for their
regular editing yet. We would love your feedback on what we have done
so far – whether it’s a problem you discovered, an aspect that you
find confusing, what area you think we should work on next, or
anything else, please do let us know.[1]
[0] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor
[1] - https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback
Yours,
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Not sure whether the Wikisource community saw this email from Guillaume.
I was thinking that maybe we should as a community be looking to avail
ourselves of this opportunity to reinvigorate how we collaborate, at least
on the holistic issues that we face through use of Mediawiki. We seem to
have all wandered off to our own little communities, and doing less in the
way of sharing.
I would like to propose that we set up something as a standalone subject
within the Wikisource: namespace, or as a subpage of
Wikisource:Scriptorium. I was thinking that each subject could be a
separate subpage, allowing discussion on talk pages. Then summarising back
to the main page which could be reflected back to the WMF community as per
the below subject requests.
Things that I see that we could also look to better as a community
* Discussions on extensions that could be universally useful
* Configurations of tools that have a cross language interest
* Better utilising some of the great work that Tpt has been doing on
ProofreadPage
* Bug issues as we now have regular updates
* Better support the smaller WS communities who don't have the people or
knowledge resources taht come with a biger community
I know that there has been stuff that has been happening at frWS and enWS
that has been shared between us, but we should be doing more broadly.
Regards, Andrew
-------- Original Message --------
Subject: [Wikitech-ambassadors] Local discussions about how to improve
communication between users and developers
Date: Fri, 7 Dec 2012 17:03:52 +0100
From: Guillaume Paumier <gpaumier(a)wikimedia.org>
To: "Coordination of technology deployments across languages/projects"
<wikitech-ambassadors(a)lists.wikimedia.org>
Reply-To: Coordination of technology deployments across languages/projects
<wikitech-ambassadors(a)lists.wikimedia.org>
Greetings,
Summary: I'm trying to get comments and ideas on how to improve
communication between developers and Wikimedia editors, and I'd like
to ask the help of people on this list to ask your local communities
what they think, and post the results of those discussions here.
Longer version:
Communication between Wikimedia contributors and "tech people"
(primarily MediaWiki developers, but also designers and other
engineers) hasn't always been ideal. In recent years, Wikimedia
employees have made efforts to become more transparent, but what I'd
like to discuss today is how we can better engage in true
collaboration and 2-way discussion, not just reports and
announcements. It's easy to post a link to a new feature that's
already been implemented, and tell users "Please provide feedback!".
It's much more difficult to truly collaborate every step of the way,
from the early planning to deployment.
Some "big" tech projects sponsored by the Wikimedia Foundation are
lucky enough to have a Community Liaison who can spend a lot of time
discussing with editors, basically incarnating this 2-way
communication channel between users and engineering staff. But one
person can only do so much: they have to focus on a handful of
features, and primarily discusses with the English Wikipedia
community. We want to be able to do this for dozens of engineering
projects with hundreds of wikis, in many languages, and truly
collaborate to build new features together. Hiring hundreds of
Community Liaisons isn't really a viable option.
There are probably things in the way we do tech stuff (e.g. new
software features and deployments) that drive editors insane. You
probably have lots of ideas about what the ideal situation should be,
and how to get there: What can the developer community (staff and
volunteers) do to get there? (in the short term, medium term, long
term?) What can users do to get there?
Instead of just postulating that "The problem is X" and "The solution
is obviously Y", I've started an extensive consultation process to
learn from users, to hear you, to listen to your complaints and your
ideas on how to fix the issues. I'm hoping that this open and
collaborative thinking process will yield better results than a
one-sided analysis.
An preliminary consultation took place last month with projects in
English and French. I've summarized the initial findings and
proposals:
https://www.mediawiki.org/wiki/Technical_communications/Fall_2012_consultat…
I'm hoping that we can now expand this consultation to more projects
and more languages, with your help. It isn't feasible for me to launch
a discussion on each wiki in each language, but I'm hoping that you
can help me spread this message and start those discussions with your
local communities.
I realize this will take some of your time, but I think it's worth
spending a little time to discuss this now in order to make big
improvements later on how we communicate with each other.
I'm available to answer comments, concerns and questions.
Many thanks for your help!
--
Guillaume Paumier
Technical Communications Manager — Wikimedia Foundation
https://donate.wikimedia.org
_______________________________________________
Wikitech-ambassadors mailing list
Wikitech-ambassadors(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors