[Typo3-doc] question about the glossary

[Mark Ravitz]

 > I agree with you! But we still have this problem with "transferring" the
 > wiki information into the glossary extension/database.
 >
 > Right now I do it by hand and it works when there are not so many
 > changes or new words written. But if we wait until a certain point and
 > then want to transfer all words into the extension within a few days -
 > how do we do it then?
 > I don't want to do that by hand, and right now we have no transfer 
tool...

There is a fair possibility that this problem is solvable.  Is the wiki
running on a TYPO3 system?   Can you get the address and password
in order to log in as Admin?  Or if not can you get read access to the
database it runs on?   It's probably MySql.  I've never worked with
wikis before but it almost a guarantee that each glossary entry amounts
to a row in a table, which means you can write a query whose
output can be massaged into an insert query into the glossary program.

Have you done this kind of stuff before?

 >  > That amounts to a heck of a lot of words.  If you
 >> did have all those words well defined and cross
 >> linked it would be an incredibly valuable tool,
 >> especially for newbies.
 >
 > I think that's the goal... And I also think it is possible to achieve.
 > Things are going surprisingly (for me, at least) well.

Actually now that I think about it, I suspect it was not the original
goal.  I remember a year or so ago when people first started talking
about the glossary they kept saying 250 entries.  That might amount
to the TYPO3 general concepts, but it certainly wouldn't cover
the TypoScript objects.   I bet there's close to a thousand of those.

I've been turning this glossary problem over in my head and here's
what I think.

A glossary of only general TYPO3 concepts is great but
users are looking for a lot more.

If this is a correct list of the areas of knowledge the be covered

General typo3 concepts
PHP stuff: Global arrays, various files
TypoScript opjects/functions/properties
TSconfig ojects/properties
Backend: Modules and fields in Backend editing forms
General web and site development and database concepts

Then in the best of all possible worlds:
the glossary would cover the general concepts,
the api document would cover the PHP stuff,
the TSref would get massively rewritten and cover the
TypoScript stuff,  the context sensitive help would get redone
to cover the Backend, and the general web stuff could just get
referred somewhere else.

Unfortunately the TSref is never going to get rewritten, it's too big
a job and I doubt if the people with the knowledge to do it see the
need for it.   It's newbies who need the rewrite, not experienced
developers.

My guess is the rewritten context sensitive help won't
be detailed enough.  When you hit the key for context sensitive help
you're not going to want to see a long explanation pop up.

What's worse, all the different areas of knowledge listed above
interact with each other.

Here's my solution.

Set up a wikipedia (wiki encyclopedia).   Move the
glossary to that.  Let it continue to grow in whatever
direction it wants to grow.   Then pick and choose what
you want from it to appear in the glossary.   The context
sensitive help team could pick and choose what they want for their
project.  The TypoScript newbie documentation would be
free to grow at it's own pace, and if someone gets
serious about rewriting the TSref the info would be sitting
there waiting and usable in the mean time.

Each documentation project could use it (if they wanted to)
as a sandbox for development.  The Mediawiki
software used by Wikipdia has permissions
so that once an entry looked really good it could be protected,
while still allowing people to add to it.

The best thing about this as far as I am concerned it that
the highly organized (an thus bureaucratic) projects could continue
on their way while someone like me who sees a crying need
(say a paper on TYPO3 caching) could just jump in and start
working on it without having to jump through any hoops.

You could divide the contributors into an Admin group
where everyone as at least four or five sites worth of TYPO3
experience, who could edit and add protected
entries (and delete the junk), and an everyone else group.


Mark Ravitz