On Fri, Aug 13, 2010 at 9:13 AM, ThomasV thomasV1@gmx.de wrote:
To fully appreciate the situation, you have to know that :
- When a page is created, it comes preloaded with OCR text. Thus, the
text of the footnote is initially on the page where the footnote is written. Moving it to the previous page involves some extra work. see here : http://fr.wikisource.org/w/index.php?title=Page:S%C3%A9vign%C3%A9_-_Lettres,...
- Footnotes are not small. Footnotes can be very long. Footnotes can be
spread over more than 2 pages. In some books, footnotes can weight more than half of the total of the text. Moving around 50% of the text of a book is a real pain. Please have a look at this example, which is 3 pages long: http://en.wikisource.org/wiki/Page:Geology_and_Mineralogy_considered_with_re... While I agree that hyphenated words can easily be moved to the previous or next page, it is not practical to do so with footnotes.
- Even if we had a way to move the text of footnotes without pain, I do
not think that this convention would be adopted. Some users absolutely want to preserve the page-by-page structure of the book, even if it involves using LST and the complicated constructs that you saw.
. . .
A few years ago, I introduced the <pages/> tag, which replaces manual transclusions. This command adds a new line between all transcluded pages. Before that, with manual transclusions, it was possible to transclude 2 pages containing a hyphenated word next to eachother, not separated by a newline, so that the word was not split. This was a bad practice, at least seen by programmer, because the information needed for text rendering is not embedded in the pages; it is much better if the target page (where text is transcluded) does not need to know anything about the content of individual pages. This is why I recommended to use <pages/>, and to keep hyphenated words unsplit, on a single page.
However, users did not like that solution ; they wanted to reproduce exactly what is on the scan. In order to adapt to the new <pages/> tag, they designed those magic templates for hyphenated words. Using these templates is in no way mandatory. However, it turned out that users prefer to use them, because they make it possible to display exactly what is on the scan. And after some time, I too became convinced that these templates are a good thing, in part because they create a convention that is unambiguous. This is just another fact, that illustrates how we wikisourcers are : we want to be able to display the text in a way that faithfully reproduces the scan. And this is why I doubt that adding a possibility to display multiple scans in front of the text will change anything to the way footnotes are handled.
This is pretty convincing, but not totally. Maybe the reason that people are so adamant about keeping content on the same page is just because they have to click links back and forth to view the other pages, which is disruptive. If they could more easily see the next and previous page, and maybe a few pages beyond that if necessary, don't you think it would be much more attractive to not split things up?
As far as I can tell, there's not any way at all to go to the next or previous page from the current edit interface. You'd have to open a separate tab and switch back and forth. What if instead, the existing scrolling box could be scrolled to display the next and previous several pages as well as the current one, with some clear indication of which page is current so people don't get confused? Wouldn't that be convenient for other purposes as well, just to easily get context on what you're transcribing?
But this still doesn't help with the fact that the original OCR text is on a different page, I guess. I suspect there's a better solution here somewhere, but that might take more work, and be subtler (UI design issues). You've convinced me that your approach is pretty reasonable given the circumstances, although I wish it didn't have to intrude into unrelated extensions.
"nobody" outside of Wikisource ? I can understand that this feature is of no direct relevance to Wikipedia, but is this a reason to reject it ? it sounds a bit like "WMF==Wikipedia".
No, I'm thinking of all the typical MediaWiki users whose wikis I see all the time, and basically none of them use MediaWiki for anything like page transcription. MediaWiki is almost always used for a regular old wiki or CMS. Things like book transcription or translation are very much abnormal uses of MediaWiki. The only reason Wikisource or TranslateWiki use MediaWiki extensions at all instead of dedicated software is probably because they were associated with MediaWiki/Wikimedia to begin with.
So it would be nice if their code could be kept confined to their respective extensions, so it doesn't confuse the large majority of developers who aren't familiar with these particular narrow use-cases. But if it's not possible, then oh well.