Abbyy Fr11 Pe Key
Orestes Hardy
As a Wikibooks user, I would like to see the feature "copy this page" (source, target) next to the move-feature. This would be great for normal user extending a book without touching the original one.
Example: Lets say you would like to improve a book about the programming language "Java". The book describes version 6 and you would like to start a new book on version 8. If it is worth having both books, than I see no way to preserve the original book and edit the text with respect to the original editors.
Example: Lets say two contributors have different but strong opinions about the future of a book. This typically leads to conflicts, where some user leave the community. The copy-the-page feature would be a good technical solution to settle the conflict. -- Qwertz84 (talk) 23:17, 9 November 2015 (UTC)[reply]
Djvu files are a very interesting open format for full book digitalization, but mediawiki uses them only as "proofreading tools". On the contrary, they could be an interesting output of wikisource work, working about thoroughly editing of text layer and fully using their metadata. Even when they are used simply as "proofreading tools", much work could be done using details of text layer mapping, since it contains interesting suggestions about formatting (text alignment and indentation, text size, paragraphs, blocks...) presently not used at all.
Just as many other wikisource users I appreciate a lot Internet Archive digitalization service, and I use it as deeply as I can (djvu files being only one from many uses of the rich file set that can be downloaded: collection of high-resolution jp2 images and abbyy xml being really extremely interesting).
I'd like that mediawiki should implement a similar digitalizing environment, but with a wiki approach and a wikisource-oriented philosophy, to share the best possible applications to pre-OCR jobs of book page images (splitting, rotating, cropping, dewrapping... in brief, "scantailoring" images), saving excellent lossless images from pre-OCR work; then the best possible OCR should be done, with ABBYY OCR engine or similar software if any, saving both text and full-detail OCR xml; then excellent images and best possible OCR text should be used to produce excellent seachable pdf and djvu files; finally - and this step would be really "wiki" - embedded text should be fixed by usual user revision work done into wikisource.
Panjab Digital Library has 1791 manuscripts and 8996 books on their website. All the manuscripts are in public domain and many books are also in public domain. Most of the manuscripts and books are in Punjabi language but some of them are in English, Hindi and Persian as well. They have digitized everything in form of images and they are not searchable. They have uploaded images in such a form that it is quite difficult to download them. I think a tool should be created to download all the manuscripts and books which are in Public domain. This will help in developing Punjabi Wikisource as well as Punjab related content on other Wikisources. This will again help in improving other projects as well. --Satdeep Gill (talk) 07:31, 13 November 2015 (UTC)[reply]
For a long time Indic languages Wikisource projects depended totally on manual proofreading, which not only wasted a lot of time, but also a lot of energy. Recently Google has released OCR software for more than 20 Indic languages. This software is far far better and accurate than the previous OCRs. But it has many limitations. Uploading the same large file two times (one time for Google OCR and another at Commons) is not an easy solution for most of the contributors, as Internet connection is way slow in India. What I suggest is to develop a tool which can feed the uploaded pdf or djvu files of Commons directly to Google OCRs, so that uploading them 2 times can be avoided. -- Bodhisattwa (talk) 13:50, 10 November 2015 (UTC)[reply]
Currently, Wikisource is using the old but reliable text editor. This requires all Wikisource contributors to know lots of templates that are different from one Wikisource language to another. Having a special version of the Visual Editor, adapted for the Wikisource needs, would facilitate inter-language help on Wikisource and bring ease to new contributors on the Wikisource projects. By having selected buttons on this adapted Visual Editor for titles, centering, left or right margins text, tracing lines, etc, would be easy to learn, especially if those are derived from a word processor general look and contribute to bring people on different language Wikisource...
Placing a title in French, in English, in Spanish or Croatian would now be the same thing : selecting the text and pressing a button... not use a different named-template depending on which Wikisource you are. Many people could help proofread pages in different languages, for example, with a global project of the week... Myself, being a french-speaking canadian, yes, I could proofread in French, English, Russian, Ukrainian, Spanish, but I'd need to know all the different templates in all these languages,and as my level of speaking and understanding in these languages are not as fluent as my native language, it is sometimes difficult to find and search on the other Wikisource projects... But nothing would prevent me from helping on any of those or even an Italian, Bulgarian or Portuguese special projects... These are the same fonts... Proofreading only needs us to be able to compare the orignal text of the book and the text transcribed... But not knowing all the templates on the different other wikisource prevent me of helping other communities...
Comment is this really a technical problem? do we really want all links? (nd just edition or works/exemplar too ? for some works, links can be longer than the text itself, eg. Tales or Bible books like Book of Genesis... for Wikisource Wikipedia links, shouldn't the wikipedia article be linked to the work page on Wikisource (which is actually done I think, and it.ws has an Opera namespace dedicated for that). I wonder if we maybe don't need a whole new system for navigation on Wikisource (similarly the Author: pages done by hand seems a non-sens to me too). Cdlt, VIGNERON * discut. 16:53, 8 November 2016 (UTC)[reply]
The community of editors, first, and the community of readers, later. The idea is to have better and more logic framework for Wikisource, which in time will allow better tools, a more easier workflow, and even better analytics for the community so that they understand what's liked and read on WS.
Comment At WS, we "faithfully transcribe" original source texts. Therefore, addressing OCR errors is one thing, but misspellings and archaic spellings that appear in the original text should usually remain after transcription. Such a tool may confuse a new user who is prompted to make a change that shouldn't be made. Also, a spelling and typo checker may create a dependency on the tool by users, assuming that a "clean" page means all is well when other errors may be lurking. Just as many errors may be found in the end. Nothing beats old-fashioned proofreading letter-by-letter, word-by-word, line-by-line, in my opinion. Londonjackbooks (talk) 11:05, 7 December 2016 (UTC)[reply]
One crucial part of it as it relates to Wikisource is that it's possible for OAI-PMH consumers to specify certain search criteria (such as a particular collection, or category, or author, etc.) when they only want to harvest those works.
For example, the National Library of Australia's Trove system could harvest all Wikisource material relating to or originating in Australia, and then any library user would see Wikisource items in their search results.
THIS is actually a super great idea!! Specially with slow internet connections, that have to reload over and over again the same UI elements, and, in my case at least, not always all the javascripts are loaded, so i need to reload the page a few times to start working. --Ninovolador (talk) 13:09, 19 November 2016 (UTC)[reply]
b37509886e