Wikisource-l

wikisource-l@lists.wikimedia.org

4 participants
1318 discussions

MARCsman
by Andrea Zanni 04 Jan '13

04 Jan '13

This should be of our interest... https://meta.wikimedia.org/wiki/MARCsman The tool can import MARC data from Library of Congress into Commons. Aubrey

2 1

Re: [Wikisource-l] [Textbook-l] [Fwd: Adam Hyde] Booktype project at WMF for PediaPress etc.
by Federico Leva (Nemo) 13 Dec '12

13 Dec '12

adam(a)flossmanuals.net, 28/11/2012 11:57: >> See >> http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65398 >> This is relevant for all projects heavily using the Collection >> extension, I guess. >> > > also happy to discuss anything here if you like. You may wish to check out > the following: > http://bookjs.net > > that is part of the tech I will discuss if there is to be a presentation Update: looks like this will happen today at 20.30 UTC: https://www.mediawiki.org/wiki/Meetings/2012-12-13 It would also be interesting to discuss the use of Translate https://www.mediawiki.org/wiki/Extension:Translate for free manuals/docs, given https://lwn.net/Articles/527966/ Nemo

1 0

Fwd: [Wikimedia-l] Alpha version of the VisualEditor now available on the English Wikipedia
by Andrea Zanni 13 Dec '12

13 Dec '12

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

3 2

Fwd: [Wikitech-ambassadors] Local discussions about how to improve communication between users and developers
by billinghurst 09 Dec '12

09 Dec '12

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

2 1

Fwd: [Wikitech-l] LabeledSectionTransclusion performance problems
by Guillaume Paumier 30 Nov '12

30 Nov '12

Forwarding to this list because Wikisource makes heavy use of LabeledSectionTransclusion. (forwarding from my personal address because the other isn't subscribed to this list) ---------- Forwarded message ---------- From: Guillaume Paumier <gpaumier(a)wikimedia.org> Date: Fri, Nov 30, 2012 at 1:09 PM Subject: Re: [Wikitech-l] LabeledSectionTransclusion performance problems To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> On Fri, Nov 30, 2012 at 10:07 AM, Merlijn van Deen <valhallasw(a)arctus.nl> wrote: > > After the new version of LabeledSectionTransclusion (LST) was deployed on > itwikisource, performance issues popped up. itwikisource's main page makes > heavy use of LST, and the new version is clearly heavier than the old one. As a sidenote: because of the performance issues, the most recent changes to the LST extension will probably be reverted today (Friday, November 30). If you made changes to articles or templates to accommodate the new version or benefit from new features, you may want to revert those changes temporarily. -- Guillaume Paumier

1 0

New LabeledSectionTransclusion code breaks Wikisource
by Federico Leva (Nemo) 30 Nov '12

30 Nov '12

See <http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064741.html> The new version was disabled on at least some Wikisources and the changes will also be reverted in the code until fixed, apparently, but they may come back. <https://wikisource.org/w/index.php?title=Wikisource:Scriptorium&diff=339889…> Nemo

1 0

[Fwd: Adam Hyde] Booktype project at WMF for PediaPress etc.
by Federico Leva (Nemo) 28 Nov '12

28 Nov '12

See http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65398 This is relevant for all projects heavily using the Collection extension, I guess. Nemo

1 0

Fwd: [Wikimedia-l] Creating Wikikultur
by Luiz Augusto 28 Nov '12

28 Nov '12

FYI, proposal for a new Wikimedia project or Wikibooks/Wikisource inclusion criteria ---------- Mensagem encaminhada ---------- De: "Mathieu Stumpf" <psychoslave(a)culture-libre.org> Data: 27/11/2012 14:37 Assunto: [Wikimedia-l] Creating Wikikultur Para: <Wikimedia-l(a)lists.wikimedia.org> Hello, I just added this proposition : http://meta.wikimedia.org/** wiki/Wikikultur <http://meta.wikimedia.org/wiki/Wikikultur> Here is the summary : Currently there are still some digital works which can not be published on a wikimedia projects, because none of them have the right editorial guideline to host them. Things like original poetry, songs, essays, theses, novels, etc., wether they were already previously published or not. It would be great to see wikimedia launch a project to host this kind of works. The no original research for wikipedia is understable and very important of course. Now what's relevant for an encyclopedia may not fit others projects which need different editorial guidelines. In existing projects Wikibooks is too pedagogic works oriented, and wikisource won't accept works which were not previously published elsewhere. Moreover, one may argue that it would be a good way to softly evacuate originals works from wikipedia, with a message like "your contribution contains original claims, wikipedia is not the place to publish this kind of content, but you could share your original work on wikikultur". Then eventualy, the wikipedia article could use wikikultur arcticles as references. This would give access to authoring information (eventually anonymous/IP claims), and all avantages of a free/libre work on a wiki. For example, we may have statistics on articles, so we can check if it's not used as a reference of an over represented point of view in an wikipedia article. On artistics topics, I think it would really help to boost the free-libre culture movement to have a place where every artists can directly experiment what it means to share and build together, with an audience intertwinned with other mediawiki projects. ---- It looks like other proposed projects would be included in such a project, like Wikiessay (I just discovered and I'm gonna read others projects description, sorry), but others aspect don't seem - at first glance - to be covered, like artistics topics. Kind regards, mathieu -- Association Culture-Libre http://www.culture-libre.org/ ______________________________**_________________ Wikimedia-l mailing list Wikimedia-l(a)lists.wikimedia.**org <Wikimedia-l(a)lists.wikimedia.org> Unsubscribe: https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l<https://lists.wikimedia.org/mailman/listinfo/wikimedia-l>

1 0

pdftotext
by Lars Aronsson 22 Nov '12

22 Nov '12

Is the "pdftotext" program used when extracting the OCR text layer from a PDF file? In this book, http://fr.wikisource.org/wiki/Livre:Liste_provisoire_des_noms_destines.pdf it seems that using "pdftotext -raw" would produce a better result than the current one. If you download the source PDF file and try to run pdftotext with and without the -raw option, you will see a difference in how some very boldface words are produced: H e l l o (without -raw) and Hello (with -raw), respectively; and also in the column separation of some pages, e.g. page 81 (De Roster--Herborn), where Dyck is followed by E (with -raw) or G (without -raw). The man page for pdftotext says -raw is deprecated, but I don't understand why, as it produces the best result. -- Lars Aronsson (lars(a)aronsson.se) Projekt Runeberg - fri nordisk litteratur - http://runeberg.org/

1 0

Re: [Wikisource-l] [Mediawiki-i18n] Extension to wrap certain characters in a span
by Federico Leva (Nemo) 19 Nov '12

19 Nov '12

Wikisource is using WebFonts (in some subdomains): how are the language codes added there? Nemo Nick White, 19/11/2012 10:51: > In case the previous description was unclear, below is an example of > what the extension does: > > original wikitext: > > Hello this is English, τηφσ ισ θοδδω, and back to English again. > > processed to become this: > > Hello this is English, <span lang="grc">τηφσ ισ θοδδω,</span> and back to English again. > > The span attributes can be configured with a global configuration > variable, as can the range of characters that should be enclosed in > it. > > Again, any response would be very welcome. > > Nick > > _______________________________________________ > Mediawiki-i18n mailing list > Mediawiki-i18n(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n >

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Wikisource-l