I'm not sure if I understand Alex's idea,

but I understand the issue of having 2 different namespaces, one for editing and one for reading.

I think it's a great idea, but we should improve a lot the usability of that and ease the navigation from one ns to the other.

For exaple, we should allow the reader to discover a typo in the ns0 and with one-click go and fix it, and then come back with a single click.

For example, could we have a [edit] or [fix] label near the SAL icon in the ns0?

Do we have any idea/tool to make pass from the nsPage to the ns0 in a single click in the right page/chapter?

Nevertheless: are we digitalizing works or are we digitalizing books? It's different.

I really don't have an easy answer for this.

My feeling is that *our software is not ready* for this kind of things.

For example, I don't think we should allow TEI with the wikitext.

We will, maybe, when the visual editor is ready.

Or maybe better we should have definite namespace (like nsTEI), which would grab the text from the nsPage or ns0 and allwo TEI use.

In brief, my proposal is: can we consider the possibility to bring into nsPage any structural/logic data needed to build any possible non-paged representation of a work?

Again, I don't have a clear answer.

It's true that sometimes we need a place for any structural/logic data. I saw your experiments with Lua modules in some work subpages, and I can even imagine a wikibase extension

that allow wikisource to store, for example, SAL data there.

But it's complex and I'd like a much broader discussion about these (visionary and very cool) ideas.

Aubrey

Alex

2013/8/26 billinghurst <billinghurst@gmail.com>

On Sun, 25 Aug 2013 07:46:22 +0200, Alex Brollo <alex.brollo@gmail.com>
wrote:

> Into a recent talk at en.source Scriptorium, it has been told that
nsPage
> can be viewed merely as a proofreading tool, the ns0 transclusion/text
> being the real core of source content.
>
> I have a different opinion, since I see nsPage code as the real core of
> source content, ns0 being merely a derived content, that could be
obtained
> with complete automation with a set of data wrapped into a Lua/Scribunto
> set of structural data (wrapping any needed data for header template and
> for pages tag), so that any ns0 page/subpage could be obtained with a
> template {{Derive|index base page name}}.
>
> Giving to nsPage such a core content role, it will be much simpler to
wrap
> into it TEI data, and any POV related to different styles of
> chapter/sections structure/naming could be avoided; html rendering will
be
> unchanged, so saving IMHO conversion in ePub.
>
> What do you think about?
>
> Alex brollo

I am fairly certain that 95% of our transcribers would have little or no
concept about which you are talking, and I am not certain that I do either.
Once we get out of the scope of the obvious, further suggestions start to
be difficult.

The concept that we utilise at enWS is that
* Page: ns is a working, non-presentation area. It is a means for
formatting text for transclusion to the main ns (for straight
transcription) and for translation (for WS sourced translations).
* Main ns is the presentation layer of the work produced by the author.

We are not into the slavish concept of "the page" as produced by the
printer as its own entity beyond it being a carriage for the text. I would
think that any further interpretation about structural data is getting too
weighed down in other considerations, not the concept of the capturing of
the words of an author.

Regards, Billinghurst

_______________________________________________
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l

_______________________________________________
Wikisource-l mailing list
Wikisource-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l