On Fri, Aug 13, 2010 at 9:13 AM, ThomasV <thomasV1(a)gmx.de> wrote:
To fully appreciate the situation, you have to know
that :
1. 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…
2. 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_r…
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.
3. 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.