> > Not to nitpick, but those are Namespaces not categories.  Categories do get
> > their own Namespace though (Category:).
Yeah.

> So that is the change that will take some work-- right now there's
> code to process uploading files, and code to save articles... the file
> upload code is not run on article text to be saved.

A note which I made a few weeks ago on wikimedia regarding this "work". I cite:
"I think to realize such a feature an expert Wiki-programmer should only need 
at most a few hours to create the necessary context -- correct interpretation 
and display of this kind of SVG-file."

Am I wrong?   (with "this kind of SVG-file", I meant the raw SVG-code followed
by further text intended to be its description which make up the whole SVG-page)


For technical implementation, one should start with the article/text-context as
new SVG-namespace/context. Then make this bisection into SVG-code and remainder
text of any created/changed SVG-page and make further checking/operations
 of/for the SVG-code like on/of uploaded SVG-files currently (and checking of
the reaminder text section, like currently occurs on text-pages ;) ).
Later when displaying a SVG-page this bisection works like displaying a
current SVG-file, except that the description is already (the 2nd) part of
the SVG-page. When calling internally for displaying the SVG-content, via
[[SVG:myPic.svg|thumb|...]] this 2nd part is completely ignored and only the
1st part (SVG-code) is displayed as a (transformed) bitmap image.   IMHO

Most difficult seems to me to efficiently make this bisection recognization.
But this is like parsing an SVG-file until its final </svg>-token and memorize
this position. Storing and maintaining is trivial (a further length parameter
to the SVG-page does the job).


Thanks anyway for your thoughts and support,
Achim

_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to