With the deployment of Wikidata it is a good moment to re-examine what
"Index" pages are and what should be their function.
The most direct transition to a Wikidata-supported Wikisource could be
something like this:
That would allow:
- to share data book data between Commons, Wikisource and Wikipedia
- to update it, when any of the sites has been updated
- to facilitate better search functions (like searches by author, or topic,
limiting the date range or the language)
That would only apply to those texts which use a "Index:" page, so now the
question is, what do we do with books that do not have supporting scans
(and therefore no index page)?
Some possible options:
a) ignore pages without sources and focus only on works with supporting
b) use ns0 pages also as data containers (instead of, or in addition to
c) create "Index:" pages for all works, with or without scans. Use that
instead of "Template:Textinfo"
Personally I prefer "option c", even if it would require to rename "Index:"
to "Source:" to make more clear what are those pages, however I would like
to hear the opinion of other wikisourcerors about this.
I'm testing a template [:it:s:Template:Pg]] (calling a Lua module) that
fastly converts book page numbers, passed as the unique parameter to the
template, into links to right djvu pages, without any need to add delta
parameters and linking any format for page number (arabic, roman, other...)
since page numbers are seen as strings.
The Lua script reads a data page, containing tables for conversion book
page->djvu page and reverse, using mw.loadData() function for max
efficiency (often there are dozens, sometimes hundreds of links to pages
into a single book page; ity happens into analytical indexes, glossaries
and so on).
The Lua data page is written in a eyeblink by a js script, which reads and
parses html of Index: page, produced by pagelist tag; so it's very
comfortable to fill such data page and to update it, if pagelist parameters
Is this "beginner's Lua exercise" someway interesting/inspiring in your
On Sun, Jun 2, 2013 at 7:21 AM, Mathieu Stumpf <
> Interesting, but why make a central code repository only for
> Wikisource ?
There are several reasons for this.
- trying to support all projects at once might be too much for a grantee to
do in 3 months.
- it is an experience to learn from, and it will have to be decided if it
can be applied broadly or substituted for some better method
- wikisource has a central location that can be used for this purpose,
other projects don't have it specifically. It could be "meta", but that
should be discussed
Hi Jane, hi Alex,
Yes, I agree with you that a centralized Wikisource would be quite
meaningful, specially now that projects like Wikidata have shown that it is
possible to have both localization and centralization living in harmony.
I know that Doug (cc'ed) did some experiments with this goal in mind, but I
have no idea how far he is now.
Apart from the technical challenge, it also worries me the social aspect.
Wikisourcerors from each Wikisource and have lived in isolation from each
other for a long time. How would be a reunification perceived by the
different communities? Would it be something wanted?
Andrea and me have the pending task of contacting the communities, so this
is something that we should bring up among other important topics (like the
creation of a Wikisource User Group:
The OPW is a grant program for students similar to Google Summer of Code
focused on helping bring more female contributors to open source projects.
So yes, it is a gendergap project, but we can offer wikisource-related
projects as we did with GsoC.
PS: Some of those plates are quite scary... I love them :)
On Sat, Jun 1, 2013 at 4:12 AM, Jane Darnell <jane023(a)gmail.com> wrote:
> Hi David and Alex,
> I am also starting to think that one project would be a whole lot
> simpler, especially given the lack of cross-referencing between
> projects, which would be nice to have in the wikisource of many
> popular wikipedia languages - especially for translated texts.
> Years ago, while researching an urban legend, I took some photographs
> of the engravings and the table of contents of a Latin book and its
> Dutch translation a century later. At the time I was toying with the
> idea of cross referencing the stories but realized quickly there was
> no way to do this on Wikisource. I put my scans here:
> Wouldn't it be easier to have just one Wikisource and have all
> language-related information reside in interface layers and for the
> language of texts, the category structure? This would make the Lua
> interface easier to achieve and work on.
> David, do you mean by "Outreach Program for Women" to refer to a
> specific wikisource project other than the general ones we have for
> the gendergap project?
> 2013/5/31, Alex Brollo <alex.brollo(a)gmail.com>:
> > I agree fully Micru.
> > Obviously, my dream is something much simpler and clear-cut: a unique
> > wikisource for all languages, since an unique project for any textual
> > is needed IMHO just as a common project for any non-textual media is
> > running: Commons; and a common project for data now exists: Wikidata.
> > And now, let's go to explore Lua a little bit more.... I presume, that
> > mw.loaderData() can read a table of Lua functions too, if I understand
> > table features. So, shared modules could perhaps be hosted into one data
> > module only. Let's try ....
> > Alex
> > 2013/5/31 David Cuenca <dacuetu(a)gmail.com>
> >> Hi all,
> >> After a talk with Brad Jorsch during the Hackathon (thanks again Brad
> >> your patience), it became clear to me that Lua modules can be localized
> >> either by using system messages or by getting the project language code
> >> (mw.getContentLanguage().getCode()) and then switching the message. This
> >> second option is less integrated with the translation system, but can
> >> serve
> >> as intermediate step to get things running.
> >> For Wikisource it would be nice to have a central repository (sitting on
> >> wikisource.org) of localized Lua modules and associated templates. The
> >> documentation could be translated using Extension:Translate. These
> >> modules,
> >> templates and associated documentation would be then synchronized with
> >> all
> >> the language wikisources that subscribe to an opt-in list. Users would
> >> then advised to modify the central module, thus all language versions
> >> would
> >> benefit of the improvements. This could be the first experiment of
> >> a
> >> centralized repository of modules.
> >> What do you think of this? Would be anyone available to mentor an
> >> Outreach
> >> Program for Women project?
> >> Thanks,
> >> David Cuenca --Micru
> >> _______________________________________________
> >> Wikisource-l mailing list
> >> Wikisource-l(a)lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikisource-l
> Wikisource-l mailing list
Etiamsi omnes, ego non
After a talk with Brad Jorsch during the Hackathon (thanks again Brad for
your patience), it became clear to me that Lua modules can be localized
either by using system messages or by getting the project language code
(mw.getContentLanguage().getCode()) and then switching the message. This
second option is less integrated with the translation system, but can serve
as intermediate step to get things running.
For Wikisource it would be nice to have a central repository (sitting on
wikisource.org) of localized Lua modules and associated templates. The
documentation could be translated using Extension:Translate. These modules,
templates and associated documentation would be then synchronized with all
the language wikisources that subscribe to an opt-in list. Users would be
then advised to modify the central module, thus all language versions would
benefit of the improvements. This could be the first experiment of having a
centralized repository of modules.
What do you think of this? Would be anyone available to mentor an Outreach
Program for Women project?
David Cuenca --Micru