[Wikisource-l] [Wikitech-l] Wikisource bugs

ThomasV thomasV1 at gmx.de
Mon Jul 5 08:45:30 UTC 2010


I do not agree with you on namespaces.

I think that the "Page" namespace is the
best way to handle the separattion between
the physical object (a book and its pages)
and the logical object that we present to
readers (the text, divided in sections or chapters)

The "Index" namespace is probably not as necessary
as the "Page" namespace; if wikisource was using only
djvu or pdf files, it would indeed be possible to go away
with it, and to use the "File:" page for that purpose.
However, there are still lots of projects that do not use
multipage file formats ; we want to keep backward compatibility.

Thomas


Lars Aronsson a écrit :
> I'd like to discuss some far more visionary changes
> in how Wikisource works, but all you can talk about are
> these two stages of proofreading.
>
> Let me start from another angle: Does anybody have
> experience from teaching beginners how to contribute
> to Wikisource? What are the hardest concepts to explain?
> I think we should compile and rank the current obstacles
> to the growth of Wikisource.
>
> Just as one example, I would put the multiple namespaces
> (Index: and Page:) pretty high on that list, and I think
> that a redesign could do away with them. There was indeed
> a bug report filed for something similar, from the Polish
> community, that wanted to disconnect the naming of Index
> pages from the naming of PDF/Djvu files:
>
> "<pagelist> should have file parameter",
> https://bugzilla.wikimedia.org/show_bug.cgi?id=21398
>
> ThomasV replied with "WONTFIX", which is understandable
> since this is not a simple bug fix, but a more complicated
> change of architecture. The problem is that this
> architecture was never documented, so we don't know
> which the design decisions are. Or was it?
>
> This is just one example of how Wikisource is really
> overly complicated, putting extra burden on newcomers,
> and where Wikisource would benefit from a redesign.
> But my suggestion is that we start to compile a catalog
> of such problems, rather than submitting bug reports.
> Where is a good place to start?
>
>
>   




More information about the Wikisource-l mailing list