Re: [Wikisource-l] IA-Upload (was: Budget for Wikisource)

[Thomas PT]

Changing the topic as the conversation has diverged.

> Not sure how Sam and Tpt solved that issue.

It's not solved yet at my knowledge.

Thomas

> Le 10 mai 2017 à 18:03, Andrea Zanni  a écrit :
> 
> It may be.
> Not sure how Sam and Tpt solved that issue.
> 
> Aubrey
> 
> On Wed, May 10, 2017 at 6:01 PM, Philippe Elie  wrote:
> On Wed, 10 May 2017 at 18:00 +0200, Andrea Zanni wrote:
> 
> > >
> > > There isn't also a trend when converting from jp2 --> pdf to produce
> > > too big djvu?
> > >
> >
> > May you please explain it better? I don't understand.
> >
> 
> Aren't djvu produced often too big?
> 
> --
> Phe
> 
> ___
> Wikisource-l mailing list
> Wikisource-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikisource-l



signature.asc
Description: Message signed with OpenPGP
___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] Wikimedia Strategy

[Thomas PT]

A maybe simpler metric: the top 1000 Wikipedia articles about works per page 
view.

Thomas

> Le 11 avr. 2017 à 09:42, mathieu stumpf guntz  
> a écrit :
> 
> Hi Nemo,
> 
> We may establish a list a the "1000 works that every Wikisource should have" 
> (with translation possibly needed).
> 
> What metric could we use to define such a list? Maybe reference frequency, 
> but it requires statistics whose availability is unknown to me.
> 
> Statistically,
> psychoslave
> 
> Le 29/03/2017 à 08:30, Federico Leva (Nemo) a écrit :
>> One issue sometimes raised about Wikisource is how we know that we're 
>> working on the "right" books. Internet Archive is planning to textbooks 
>> starting from those which are most frequently assigned in USA schools:
>> http://blog.archive.org/2017/03/29/books-donated-for-macarthur-foundation-100change-challenge-from-bookmooch-users/
>> 
>> I was surprised to learn a project like OpenSyllabus exists and works, I 
>> emailed them to ask what it would take to do the same for other 
>> languages/geographies.
>> 
>> Nemo
>> 
>> ___
>> Wikisource-l mailing list
>> Wikisource-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikisource-l
> 
> 
> ___
> Wikisource-l mailing list
> Wikisource-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikisource-l



signature.asc
Description: Message signed with OpenPGP
___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] Drop OAI-PMH repository of Index: pages

[Thomas PT]

Hello Andrea,

> I guess it could be very useful to use for importing those data into Wikidata.

Even when removing the OAI-PMH API we could still extract data from the Index: 
page serialization. It's a bit more difficult but not much more (and definitely 
far less than the entity matching problem).

>  The problem with those API is that it works only it Index pages, which are 
> only a fraction of the "book" entity on Wikisource. Index pages are not 
> linked in a structured way with their ns0 pages, and this is a problem for us.

It's possible to retrieve the ns0 pages that uses a given Index: page using the 
 tag (you just have to retrieve the list of transclusions of the Index: 
page as if it where a regular template).

> Ideally, we would know when a Index page has only one ns0 page, and we would 
> use the same set of data to create an entity (or more) into Wikidata.

Yes. What we could do is see if the "Title" field of the index pages has only 
one link to a ns0 page and consider this is the "one" ns0 page. An other 
possible thing is, when the header feature of the  tag is use, retrieve 
the pages that use the automatic summary feature and, if there is only one, 
consider this as the "one".

> and I don't know if that uses your API.

I believe he doesn't but we should definitely ask him if it's useful for his 
use case.

Thomas

> Le 31 déc. 2016 à 12:58, Andrea Zanni <zanni.andre...@gmail.com> a écrit :
> 
> Hi Thomas.
> 
> I used, one year ago, the API: I downloaded the data from the Index pages, 
> and I think that it would be good to have it while we still don't have 
> Wikidata.
> I guess it could be very useful to use for importing those data into Wikidata.
> 
> The problem with those API is that it works only it Index pages, which are 
> only a fraction of the "book" entity on Wikisource. Index pages are not 
> linked in a structured way with their ns0 pages, and this is a problem for us.
> 
> Ideally, we would know when a Index page has only one ns0 page, and we would 
> use the same set of data to create an entity (or more) into Wikidata.
> 
> I know that Sam is trying to develop a similar tool:
> https://tools.wmflabs.org/ws-search/
> and I don't know if that uses your API.
> 
> Aubrey
> 
> On Fri, Dec 30, 2016 at 6:15 PM, Thomas PT <thoma...@hotmail.fr> wrote:
> I definitely used the pageviews API. So I understand now why the count was 0. 
> Sorry for the false info and thank you for your correction.
> 
> But my proposal still stands as I do not know any actual user of the API.
> 
> Thomas
> 
> > Le 30 déc. 2016 à 18:11, Federico Leva (Nemo) <nemow...@gmail.com> a écrit :
> >
> > Sorry for the double message.
> >
> > Thomas PT, 30/12/2016 17:31:
> >> According to the Wikimedia PageView statistic tool
> >
> > Did you literally use https://tools.wmflabs.org/pageviews , or have you 
> > asked for real requests data? The pageviews API doesn't count requests to 
> > the OAI-PMH endpoint at all, because they have "content-type: text/xml" 
> > while text/html is required: 
> > https://meta.wikimedia.org/wiki/Research:Page_view#Definition
> >
> > Only people with access to 
> > https://wikitech.wikimedia.org/wiki/Analytics/Data/Webrequest#wmf.webrequest
> >  can extract data on how much it's used.
> >
> > Nemo
> >
> > ___
> > Wikisource-l mailing list
> > Wikisource-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikisource-l
> 
> ___
> Wikisource-l mailing list
> Wikisource-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikisource-l
> 
> ___
> Wikisource-l mailing list
> Wikisource-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikisource-l



signature.asc
Description: Message signed with OpenPGP
___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] Drop OAI-PMH repository of Index: pages

[Thomas PT]

I definitely used the pageviews API. So I understand now why the count was 0. 
Sorry for the false info and thank you for your correction.

But my proposal still stands as I do not know any actual user of the API.

Thomas

> Le 30 déc. 2016 à 18:11, Federico Leva (Nemo) <nemow...@gmail.com> a écrit :
> 
> Sorry for the double message.
> 
> Thomas PT, 30/12/2016 17:31:
>> According to the Wikimedia PageView statistic tool
> 
> Did you literally use https://tools.wmflabs.org/pageviews , or have you asked 
> for real requests data? The pageviews API doesn't count requests to the 
> OAI-PMH endpoint at all, because they have "content-type: text/xml" while 
> text/html is required: 
> https://meta.wikimedia.org/wiki/Research:Page_view#Definition
> 
> Only people with access to 
> https://wikitech.wikimedia.org/wiki/Analytics/Data/Webrequest#wmf.webrequest 
> can extract data on how much it's used.
> 
> Nemo
> 
> ___
> Wikisource-l mailing list
> Wikisource-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikisource-l

___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

[Wikisource-l] Fwd: [Wikitech-ambassadors] Your help needed: Community Wishlist Survey 2016

[Thomas PT]

Hello everyone,

The Wikimedia Foundation Community Tech team has launched a new "Community 
Wishlist Survey".
Last year survey allowed us to get WMF staff time to work on using Google OCR 
in Wikisource that allowed some Indian languages Wikisources to raise and on 
VisualEditor support.

Please, take time to submit new wishes and comment them. It could be simple 
things (e.g. a new gadget for a specific workflow) or very complicated ones 
(e.g. native TEI support).

Cheers,

Thomas


Début du message réexpédié :

De: Johan Jönsson >
Objet: [Wikitech-ambassadors] Your help needed: Community Wishlist Survey 2016
Date: 7 novembre 2016 à 20:26:21 UTC+1
À: Wikitech Ambassadors 
>
Répondre à: Coordination of technology deployments across languages/projects 
>

Hi everyone,

Last year, the Community Tech team did a survey for a community wishlist to 
decide what we shoudl be working on throughout the year. Since it's useful to 
have a list of tasks from the Wikimedia communities, it's also been used by 
other developers, been the focus of Wikimedia hackathons and so on. In short, I 
think it matters.

Now we're doing the process again.

https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey

If you'd feel like spreading this in your communities, it would be much 
appreciated.

*) This is when you can suggest things. This phase will last from 7 November to 
20 November.
*) Editors who are not comfortable writing in English can write proposals in 
their language.
*) Voting will take place 28 November to 12 December.

Thanks,

//Johan Jönsson
--




___
Wikitech-ambassadors mailing list
wikitech-ambassad...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors

___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] IA Upload tool

[Thomas PT]

> Alex's idea is very bold and I like it: my only fear is that it's too bold 
> and will never be implemented. 
It's has already been implemented as a WMF tool labs tool by Phe and ia-upload 
have been modified in order to call it when no DjVu is available in IA. I'm 
planning to take some time in order to debug the current problems.

Cheers,

Thomas


> Le 30 sept. 2016 à 11:18, Andrea Zanni  a écrit :
> 
> Alex's idea is very bold and I like it: my only fear is that it's too bold 
> and will never be implemented. 
> 
> At the moment, we have not a proper alternative and independent environment 
> for working with scans: I wonder if that should be something related to 
> CropTool [1] or Commons in general. 
> 
> What I would like to see *now* (for the good is better than the best, if it's 
> quicker)
> is a working IA-Upload, with a good support for djvu (because the internet 
> archive's PDF is often very low quality). 
> 
> From what I understood from Tpt, the IA-upload tool should already do that, 
> but evidently there are issues at the moment. 
> 
> For people who know how to run a script from command line, 
> a way to generate a djvu from IA is using Alex brollo's script [2]
> 
> Ideally, I would see this script integrated with the IA Upload tool, so we 
> can use the existing
> IA > ia_upload tool > Commons > Wikisource 
> workflow, as usual. Many librarians are still using it.
> 
> Aubrey
> 
> [1] https://tools.wmflabs.org/croptool/
> [2] 
> https://it.wikisource.org/wiki/Progetto:Bot/Programmi_in_Python_per_i_bot/djvuCl.py
> 
> 
> On Fri, Sep 30, 2016 at 2:48 AM, Sam Wilson  wrote:
> 
> On Thu, 29 Sep 2016, at 07:36 PM, Andrea Zanni wrote:
>> I think that IA Upload tool is a critical step in the Wikisource workflow, 
>> and I wonder if maybe Sam (as a Community Tech employee) could dedicate some 
>> time to it. 
>> Tpt can't maintain everything by himself... 
>> For years, I've explained to *a lot* of GLAMs that uploading stuff on IA
>> and then using Wikisource is the way to do things, and I'm sure this is the 
>> standard way in other places
>> too. 
> 
> Yes, I agree: the IA-Commons-Wikisource workflow is a thing that should be 
> encouraged no end! :-)
> 
> As far as my work-programming time goes, you (I say 'you' but I just mean 
> 'not-me', for CoI reasons) just need to get tickets onto the Community-Tech 
> board, then I can perhaps look at them. Which basically means they have to 
> contribute towards a Wishlist item.
> 
> There's Wishlist #44: https://phabricator.wikimedia.org/T120785 - Implement 
> an Internet Archive-like digitalization service.
> I reckon it'd be great to be able to at least upload a PDF or Djvu with no 
> text layer, and have it create one (either on the same file, or to upload a 
> new derived file).
> 
> —Sam
> 
> 
> ___
> Wikisource-l mailing list
> Wikisource-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikisource-l
> 
> 
> ___
> Wikisource-l mailing list
> Wikisource-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikisource-l

___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] Fwd: [Wikitech-ambassadors] new beta feature: in other projects sidebar

[Thomas PT]

A small detail: this beta feature won't be enabled on wikis that already have 
the other project sidebar enabled for everyone (like the french and italian 
wikisources). For these wikis nothing should change.

Thomas

Le 15 août 2014 21:56, David Cuenca dacu...@gmail.com a écrit :
-- Forwarded message --
From: Lydia Pintscher lydia.pintsc...@wikimedia.de
Date: Fri, Aug 15, 2014 at 8:04 PM
Subject: [Wikitech-ambassadors] new beta feature: in other projects sidebar
To: wikitech-ambassadors wikitech-ambassad...@lists.wikimedia.org
Cc: Discussion list for the Wikidata project. 
wikidat...@lists.wikimedia.org


Hey folks :)

We'll be rolling out a new beta feature on August 26th/28th to
Wikipedia, Wikisource and Wikiquote. It will add a new section to the
sidebar of an article. This section will contain links to related
articles in other sister projects. Which projects are shown can be
configured per-wiki. You can find out more about it at
https://www.mediawiki.org/wiki/Beta_Features/Other_projects_sidebar

If you have any questions about this please use the discussion page of
https://www.mediawiki.org/wiki/Beta_Features/Other_projects_sidebar


Cheers
Lydia

--
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata

Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

___
Wikitech-ambassadors mailing list
wikitech-ambassad...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors



--
Etiamsi omnes, ego non
___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l
___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] Add wiki data for old wikisoure

[Thomas PT]

Hi!
OldWikisource is not supported by Wikidata yet. So no way to do it.
Regards,
Thomas

Le 6 août 2014 18:34, Jayanta Nath jayanta...@gmail.com a écrit :
Hi,

How to add wiki data for old wikisoure??

As  an example Bankim Chandra Chattopadhyay (
https://www.wikidata.org/wiki/Q377881),  there are no hindi wikisource, but
we have a author page in old at
https://wikisource.org/wiki/Author:%E0%A4%AC%E0%A4%82%E0%A4%95%E0%A4%BF%E0%A4%AE%E0%A4%9A%E0%A4%82%E0%A4%A6%E0%A5%8D%E0%A4%B0_%E0%A4%9A%E0%A4%9F%E0%A5%8D%E0%A4%9F%E0%A5%8B%E0%A4%AA%E0%A4%BE%E0%A4%A7%E0%A5%8D%E0%A4%AF%E0%A4%BE%E0%A4%AF

So how would we add this to wikidata??

Regards,

Jayanta
___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l
___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] Community logo for Wikisource

[Thomas PT]

Thanks for these amazing logos. I've also a small preference for Isarra one 
that is a little less sad and represents well what Wikisource community is: a 
part of the Wikimedia community focused on books.

Thomas

Le 18 avr. 2014 13:03, David Cuenca dacu...@gmail.com a écrit :

 On Fri, Apr 18, 2014 at 11:02 AM, Nicolas VIGNERON 
 vigneron.nico...@gmail.com wrote:

 Same thing for me ; Isarra's one looks better to me.

 The blue colours are a good reminder of the iceberg but it's a bit « sad ».


 The other one is not so happy either, but I like both :)

 Cheers,
 Micru 
___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] BookManagerv2

[Thomas PT]

I think there are some small design issues with the current implementation of 
BookManagerv2 that will make integration with Wikidata very difficult.

I'm currently writing a proposal on how we should fix them in order to have a 
powerful metadata management system in Wikisource that will be able to 
intereract nicely with Wikidata and Commons.

Thomas

Le 2 déc. 2013 10:24, Andrea Zanni zanni.andre...@gmail.com a écrit :
Mmmm: http://blog.mollywhite.net/

it seems she changed the blog, but where is the old one?

Aubrey


On Mon, Dec 2, 2013 at 10:19 AM, Jayanta Nath jayanta...@gmail.com wrote:

  I cant fond nothing final report here m:Book 
 management/Progresshttps://meta.wikimedia.org/wiki/Book_management/Progress.
 May be Molly's blog down.


 On Mon, Dec 2, 2013 at 2:42 PM, Federico Leva (Nemo) 
 nemow...@gmail.comwrote:

 AFAIK the only known status update is Project was mostly finished, but
 still has some bugs. https://www.mediawiki.org/
 wiki/Summer_of_Code_Past_Projects#Improve_support_for_book_structures

 Nemo


 ___
 Wikisource-l mailing list
 Wikisource-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikisource-l



 ___
 Wikisource-l mailing list
 Wikisource-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikisource-l


___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l
___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] [Offline-l] How important is ZIM support in Collections?

[Thomas PT]

Quantitative feedback for Wsexport un October: 
http://wsexport.wmflabs.org/tool/stat.php?month=10year=2013

Le 13 nov. 2013 10:59, Federico Leva (Nemo) nemow...@gmail.com a écrit :
Erik Moeller, 13/11/2013 06:51:
 We're re-implementing the rendering pipeline for Collections to ensure
 long-term maintainability, and our default would be to eliminate
 initially all formats except for PDF if we don't absolutely have to
 support them. I'll see if we can get some metrics on current ZIM file
 usage via the Collection extension, but it'd be nice to get
 qualitative feedback as well.

 (More background at: https://www.mediawiki.org/wiki/PDF_rendering )

All including ePub (cc Wikisource-l).

Nemo

___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l
___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] About texts without supporting files and Index: pages

[Thomas PT]

Sorry if my answer is off-topic but if metadata are stored in WIkidata, is it 
really needed to create index pages to store the same data as Wikidata?
As I see the things, we'll have bibliographical metadata on Wikidata (title, 
author, date of publication...) and data related to proofreading (proofreading 
level, table of content...) on the Index: pages. More, as the Proofread Page 
extension considers that an Index page is about a scan (ie one or more files) 
I'm not sure that Index pages about books without scan will be managed well by 
the extension.

{{header|index name}} is already done, for books with scan, by the Proofread 
Page extension with the header=1 feature. In fr Wikisource, we already use a 
Lua module to manage the Mediawiki:Proofreadpage_header_template template used 
by the header=1 feature. https://fr.wikisource.org/wiki/Module:Header_template 
This template outputs automatically metadata and navigation from the index page 
TOC (but it allows also to override data).

Tpt

Date: Tue, 11 Jun 2013 01:33:39 +0200
From: alex.bro...@gmail.com
To: wikisource-l@lists.wikimedia.org
Subject: Re: [Wikisource-l] About texts without supporting files and
Index: pages

I'm going to test what you are telling in a real Lua script; as you know, Lua 
can read the code of any page with one expensive server function only, so 
that a simple {{header|index name}} ns0 template call could read all the wiki 
code from index page, parse it, extract all its data content, and use it to 
build any html you like. No other field is needed. In it.wikisource we are 
testing something more complex, since we are exporting Index data into a local 
Lua data module, to be loaded with a mw.loadData function that is not listed  
as server-expensive; but I presume that wiki servers would not be overloaded 
by one server expensive call

If Im not going wrong, such a script could be written tomorrow by a good Lua 
programmer I'll need some more time as a beginner.  I'll test a 
MediaWiki:Proofreadpage_index_template Lua loader  parser working into ns0, 
just to see if all runs as I guess, then I'll tell you in this thread. In which 
wikisource project do you work usually?

Alex


2013/6/11 David Cuenca dacu...@gmail.com

No, it won't be stored in Wikisource, but still there is the need to present 
the information in a consistent manner.

If you want to display the information on ns0, you will end up needing the same 
fields that the Index: page is using now. 


So why not to have the same solution for both? 

It could also be a template with a reduced set of fields that expands to show 
Template:Book with linked data from Wikidata, no matter if they have 
supporting scans or not.




Micru

On Mon, Jun 10, 2013 at 6:00 PM, Alex Brollo alex.bro...@gmail.com wrote:



Simply there is no need to store data twice or more, if they are dinamically 
imported from wikidata. Such data would be simply generated by a normal 
template. Something similar to Commons media sharing: most wikipedians but 
beginners know that when you want to edit a shared media file, you must do you 
edit in Commons; there's no need to host a media file locally. 




So, IMHO a good Lua wikidata-reading library could avoid at all to store data 
in wikisource, or wikipedia, or Commons. 
Alex




2013/6/10 David Cuenca dacu...@gmail.com




@Alex: but what do you think of storing the source information in Index: 
pages for all works stored in Wikisource, even if they don't have a supporting 
scan?

That was the original question :)







About your proposed library, it would be more useful if it could modify data in 
Wikidata, not only import it. Besides, if the Wikidata client is installed in 
Wikisource, the inclusion syntax already takes care of displaying data...







Micru

On Mon, Jun 10, 2013 at 5:38 PM, Alex Brollo alex.bro...@gmail.com wrote:



I don't see the need to change deeply Index/ns0 relationship, while I 
appreciate the idea promote coherence reducing redundance (many years ago I 
painfully used dBase III - dBase IV and I learned that principle by try and 
learn).







Here: http://www.mediawiki.org/wiki/Extension_talk:Scribunto/Brainstorming a 
brief message about relationship among wikidata, commons, wikisource and any 
other project. Don't follow the link, it's so short that I copy it here (but if 
you like it, comment it there):







Scribunto-Lua and WikidataI'd like a library to get Wikidata content; it would 
be a good idea IMHO to access to Wikidata data in plain form, just as such data 
would be Lua tables/variables. --Alex brollo (talk) 13:06, 10 June 2013 (UTC)







If such a Lua library could be built, to import data from wikidata would be as 
simple, as writing a template, and data will be self-aligned. 

Alex

2013/6/10 Aarti K. Dwivedi ellydwivedi2...@gmail.com







Hi,
There was a thread some time ago where there were talks of having books 
which were born digital. These pages wouldn't have scans.

Re: [Wikisource-l] Playing with Lua, javascript and pagelist tag

[Thomas PT]

Hi!

It looks very good!
In my opinion the template will be more interesting (but also more heavy) if 
you work directly with the Index page by loading its content (local page = 
mw.title.new( 'Index:XXX.djvu' ); local text = page:getContent()) and parsing 
the pagelist tag that will give you the displayed number - number in the 
djvu conversion.

Thomas

Date: Fri, 31 May 2013 16:10:47 +0200
From: alex.bro...@gmail.com
To: wikisource-l@lists.wikimedia.org
Subject: [Wikisource-l] Playing with Lua, javascript and pagelist tag

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 are updated. 

Is this beginner's Lua exercise someway interesting/inspiring  in your 
opinion? 
Alex brollo




___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l   
  ___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] Lua modules for Wikisource

[Thomas PT]

Hi!
In French Wikisource, we have some templates already rewritten in lua like:
https://fr.wikisource.org/wiki/Module:Header_template The header template use 
by Proofread Page
https://fr.wikisource.org/wiki/Module:Classement Create clean default 
DEFAULTSORT
https://fr.wikisource.org/wiki/Module:Table for TOCs
https://fr.wikisource.org/wiki/Module:MathRoman : outputs roman number.

For commons, the issue is that, as I know, Lua doesn't support 
internationalization very well (but I think it could be done with some hacks).

Thomas

PS: I've also rewritten for French and English Wikipedia the Authority control 
template. It supports validation of some ids and fallback to Wikidata. See 
https://en.wikipedia.org/wiki/Module:Authority_control/sandbox and 
https://fr.wikipedia.org/wiki/Module:Autorité . The fallback to Wikidata 
feature is live on the French Wikipedia but not on the English one. I can help 
to adapt it to other languages.

From: zanni.andre...@gmail.com
Date: Mon, 20 May 2013 17:54:08 +0200
To: wikisource-l@lists.wikimedia.org
Subject: [Wikisource-l] Lua modules for Wikisource

Hi all,is there any Wikisource which had Lua deployed?I'm looking for a 
book/header templates re-written in Lua to copy and localize :-)(so far, I've 
seen only this one in the Italian Wikipedia 
http://it.wikipedia.org/w/index.php?title=Modulo:Tracceaction=edit)

And I'd love to see Book and Creator templates on Commons Lua-style :-)
Aubrey

___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l   
  ___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] Fwd: [Wikimedia-l] Alpha version of the VisualEditor now available on the English Wikipedia

[Thomas PT]

Hi,
Yes, some work is needed in order to make Proofread Page work with the 
VisualEditor. It's my first priority for the Proofread Page development in 2013.
A lot of work have to be done in ProofreadPage, in order to have a less hacky 
edit system, and in the VisualEditor that isn't currently really customizable.

I have discuss with the VE team a few days ago and it's in their mind to work 
for sisters projects after having made the VisualEditor working fine for 
Wikipedia. So, it's not before July if they match their roadmap. But, I'm not 
sure that the team will not work on some others project after this date. So, I 
believe that a lot of lobbying is needed if we want to see the VisualEditor 
team working on Wikisource.

I have the project to work myself for this project in order to be able to use 
the VisualEditor in page namespace when it will be launched in sisters wikis.
This work will be done in tree phases:
1 Rewrite some of the ProofreadPage code in order to allow a clean and easy 
integration of the Visual Editor (and, at the same time improve the current 
edition system).
2 Allow the VisualEditor to edit the main content of the page (ie only the main 
content, not the header, the footer and the proofreading level). It should be 
very easy if 1 is done well.
3 Integrate the Page namespace related features into the VisualEditor. This 
phase will require the help of the VisualEditor team.
What do you think about this project?
If someone want to help, I'll be very happy to work with him because it's not 
really fun to work alone. Being a genius is not required to contribute, so 
anybody that know how to code can work on it.
I've updated https://www.mediawiki.org/wiki/Extension:Proofread_Page/Roadmap
Thomas

PS: The OAI-PMH repository of index pages is now launched on Wikisources. See 
https://www.mediawiki.org/wiki/Extension:Proofread_Page for more information.

--
From: zanni.andre...@gmail.com
Date: Wed, 12 Dec 2012 10:03:22 +0100
To: wikisource-l@lists.wikimedia.org
Subject: [Wikisource-l] Fwd: [Wikimedia-l] Alpha version of the VisualEditor 
now available on the English Wikipedia

They are enabling an alpha-version of the Visual Editorin 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 haveour VE 
within the PR pages...


Aubrey


-- Forwarded message --
From: James Forrester jforres...@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 wikitec...@lists.wikimedia.org, 
wikimedi...@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.

Re: [Wikisource-l] Proofreading bug: Change not allowed

[Thomas PT]

Hi!
This bug is very strange. Its looks like it append only on italian Wikisource, 
so I think that one of your common.js script of gadget cause the bug.
This bug is impradicable it might be caused by a change of execution order of 
two script, by example your common.js (or a gadget) and scripts of 
ProofreadPage.

ProofreadPage init header, footer and quality contents from the content of the 
main textbox in its JavaScript so you mustn't supposed that the header and 
footer content is removed from the textbox when you write a script because this 
removing may occur after your script execution. 

The variables are not merged by JavaScript but directly by PHP in the function 
onEditPageImportFormData of ProofreadPage.body.php and I don't think there is 
a bug at this level because all Wikisources would be affected.

So, I think that the bug is maybe caused by:
- A script that make the initialization of textboxes fail (by example by 
changing main textbox content before execution of ProofreadPage).
- A script that make the fields empty on submitting.
- ...
Tpt

Date: Sat, 10 Nov 2012 17:09:04 +0100
From: alex.bro...@gmail.com
To: wikisource-l@lists.wikimedia.org
Subject: [Wikisource-l] Proofreading bug: Change not allowed

When proofreading pages in it.wikisource, we are plagued by this message: 
Change not allowed - You are not allowed to change the proofreading status of 
this page

Going back to failed page, we noted that:
1. quality level is reverted to 1;2. anything stored into header has been lost;
3. proofreadpage_username is set to an empty string 

The bug is impredictable, it occurs with different frequencies to different 
users when trying to edit different pages. Something wrong seems to occur when 
building the page code merging variables, header, body and footer contents. We 
wrote an emergency fixing script but it can only be called after the edit 
turns out to be wrong.

Is something similar happening into any other wikisource project?  Can you give 
us a link to understand what's happening? And - where can we find the js script 
which merges variables-header-body-footer into page code to send it to the 
server?

Alex







___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l   
  ___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] Support of non-arabic page number in page namespace

[Thomas PT]

I've made in september changes in the management of page numbers in order to 
allow the use of not-arabic page numbers.  I wasn't sure if this change doesn't 
make collateral bugs in some other parts of the software. This patch is on 
Wikisource since a month and I've not any feedbacks of bugs about that. So I 
think all works correctly.
Tpt


Federico Leva (Nemo) nemow...@gmail.com a écrit :

Thomas PT, 08/09/2012 19:21:
 You can now try these changes on labs: http://XX.wikisource.beta.wmflabs.org
 You should try translation of page number, there may be some issues with
 specific languages.

So is everything working correctly?

Nemo

___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

[Wikisource-l] News about ProofreadPage development.

[Thomas PT]

Hi !
Two big modifications have been merged into ProofreadPage trunk last week.
They will be deployed next week, Wednesday, October 31 with Mediawiki 1.21-wmf3 
and are already live on beta server: http://en.wikisource.beta.wmflabs.org

The first one is the rewriting of the edition form of the index pages in PHP in 
order to decrease loading time and add new features like an help system. A 
description have be made in OldWikisource: 
https://wikisource.org/wiki/Wikisource:ProofreadPage/Improve_index_pages#Improvement_of_the_index_form
 .

In oder to add these new features (default value, help message...), this 
rewriting introduce a new configuration message for index pages based on one 
JSON array located in Mediawiki:Proofreadpage_index_data_config . JSON format 
have chosen because it's very extensible in order to add easily new features in 
the future. This message regroup Mediawiki:proofreadpage_index_attributes and 
Mediawiki:proofreadpage_js_attributes .
The use of this new configuration way is not required in order to have time to 
improve the configuration system in the future if there are any problem and to 
allow a smooth migration. Small wikis are invited to keep using the old 
configuration way.
This format is also described on oldWikisource: 
https://wikisource.org/wiki/Wikisource:ProofreadPage/Improve_index_pages#Improvement_of_the_index_form
A migration tool have been written in order to migrate easily: 
https://toolserver.org/~tpt/upgrade/config.php

The second change, more small, change the way of configuration of Index and 
Page namespaces: the configuration will not be done in 
Mediawiki:Proofreadpage_namespace and Mediawiki:Proofreadpage_index_namespace 
but directly in PHP configuration. The support of the new configuration system 
have already been added to Wikimedia's websites configuration so their might be 
no problem. 
Description of the new configuration system: 
https://www.mediawiki.org/wiki/Extension:Proofread_Page#Namespaces

If you find bugs please report them in Bugzilla: 
https://bugzilla.wikimedia.org/enter_bug.cgi?component=ProofreadPageproduct=MediaWiki%20extensions

Thomas ( User:Tpt )

  ___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

Re: [Wikisource-l] Support of non-arabic page number in page namespace

[Thomas PT]

You can now try these changes on labs: http://XX.wikisource.beta.wmflabs.org
You should try translation of page number, there may be some issues with 
specific languages.
Thomas

Date: Sat, 8 Sep 2012 09:08:35 +0700
From: jay...@gmail.com
To: wikisource-l@lists.wikimedia.org
Subject: Re: [Wikisource-l] Support of non-arabic page number in page   
namespace

Excellent improvements. Should we test them before they are deployed? 
John Vandenberg.

sent from Galaxy Note
On Sep 8, 2012 12:03 AM, Thomas PT thoma...@hotmail.fr wrote:




Hi,
For people that doesn't know me, I contribute to the French Wikisource and I 
try to improve the Proofread Page extension.

Here is a description of some modification into Proofread Page that will be 
deployed sooner, I think next week.


1 I have made a patch in order to add support of not-arabic page number in the 
page namespace for languages that doesn't use arabic numerals: new pages of 
multi-pages books will now have a name with number in their own language. 
Existing pages can keep their names with arabic  numerals or be renamed by hand 
or with a bot in order to use not-arabic numbers.

The pagelist tag will links to pages with a localized number but, if the 
localized page doesn't exist and a page with an arabic number exist, pagelist 
will link to this page. The pages tag and the navigation inside of the page 
namespace will use the same system.

So, with this system, nothing, I hope, will be broken in wikis.

2 I have added support of wiki links to proofreadpage_page_status message.

3 I have written a change that create prp-pagequality-[1-4] HTML classes and 
add them to all links to Page namespace. These classes are done in order to 
allow people to color all links to page namespace. The old quality[1-4] classes 
can of course be ever used in order to color these links only inside of Index 
namespace.


So I hope that these improvments will increase ProofreadPage quality.
Sorry for my poor English,
Thomas (User:Tpt)
  

___

Wikisource-l mailing list

Wikisource-l@lists.wikimedia.org

https://lists.wikimedia.org/mailman/listinfo/wikisource-l




___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l   
  ___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

[Wikisource-l] Support of non-arabic page number in page namespace

[Thomas PT]

Hi,
For people that doesn't know me, I contribute to the French Wikisource and I 
try to improve the Proofread Page extension.

Here is a description of some modification into Proofread Page that will be 
deployed sooner, I think next week.

1 I have made a patch in order to add support of not-arabic page number in the 
page namespace for languages that doesn't use arabic numerals: new pages of 
multi-pages books will now have a name with number in their own language. 
Existing pages can keep their names with arabic  numerals or be renamed by hand 
or with a bot in order to use not-arabic numbers.
The pagelist tag will links to pages with a localized number but, if the 
localized page doesn't exist and a page with an arabic number exist, pagelist 
will link to this page. The pages tag and the navigation inside of the page 
namespace will use the same system.
So, with this system, nothing, I hope, will be broken in wikis.

2 I have added support of wiki links to proofreadpage_page_status message.

3 I have written a change that create prp-pagequality-[1-4] HTML classes and 
add them to all links to Page namespace. These classes are done in order to 
allow people to color all links to page namespace. The old quality[1-4] classes 
can of course be ever used in order to color these links only inside of Index 
namespace.

So I hope that these improvments will increase ProofreadPage quality.
Sorry for my poor English,
Thomas (User:Tpt)
  ___
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l