>I work with a book non-profit book publishing house in India [http://www.prathambooks.org/] and we're hoping to put together a wiki that works as a collaborative space for authors and translators and a community at large to use. Thus far, we have identified the following as requirements:

Hi!

My name is Marc and I am Project Admin for TikiWiki CMS/Groupware. I'll provide some answers and links to relevant documentation. TikiWiki has more built-in features than any other Web application I know of. It's wiki-centric but a full-featured Groupware and Content Management System.


>1.   Collate all currently available reading material for children, in multiple  languages, at one site.

One installation of TikiWiki can handle multiple languages.


>2. Host our books for on­line translations and edits and re­use in as many languages and formats as possible from across the world and this can be moderated by a group of editors and super­users and allow for these translations and derivative works to be available to the community only after a moderation and review process.

http://doc.tikiwiki.org/Wiki+Page+Staging+and+Approval


>3. As we receive new manuscripts (and we get a number of them, unsolicited, via our website) we would like the portal to function as a preliminary review process and as an adjunct to our internal ones and put these up to run through the similar flow as above.

You could build a specific workflow or use categories & wiki pages as a workflow.
http://workflow.tikiwiki.org/


>4. Pratham Books will work on the illustrations off­line (and perhaps we could also get them done on­line at a later date once the technological challenges are sorted out) and the layouts and “freeze” them so that the translations and edits can be done without having to worry about pictures and layout. A "good to have" feature would be to have the contributor(s) be able to preview their text (in multiple languages) in the final layout.

We have a new annotation plugin, (not yet stable or documented)
http://doc.tikiwiki.org/PluginAnnotation


>5. Make our artwork available as a “clipart gallery” focussed at primary school teachers who can use this work to create teaching / learning material of their own and to anyone else who might have uses for this clipart.

http://doc.tikiwiki.org/Image+Gallery


>6. Make available blank templates of books using illustrations in our catalog that people can use to weave, write and tell their own stories.

http://doc.tikiwiki.org/Content+Template


>7. Colouring charts from our illustrations, remove colour, B&W outlines.

What would you like the CMS to do, if anything?


>8. Legal Traceability and License Management. CMS/DocMgmtSytstem

http://doc.tikiwiki.org/Copyright


>9. How do we manage version control and decide on a final version?

http://doc.tikiwiki.org/Wiki+Page+Staging+and+Approval


>10. Embedding PB and associated logos and text.

What is a PB?


> 11. Real names. Users can (optionally) specify a "real name" they want to use for author credits.

Yes, and they can have unlimited things in their personal profile


>12. On-page credits. Administrators can enable an on-page paragraph giving credit to editors who've worked on a page.

Built-in to any wiki


>Features and Limitations to Keep in Mind:
> 1. Need to figure out which features are doable and which not; and in the first set, a phased approach.

Make sense. Most are built-in, as you will see.

> 2. WYSIWYG Editor

http://doc.tikiwiki.org/WYSIWYG


>   3. Plugins & API

http://dev.tikiwiki.org/Hello+World


>  4. Internationalization and localization

http://doc.tikiwiki.org/i18n
http://wiki-translation.com/CLWE+Demo+Screencast -> Very nice!


>   5. Scalability through multiple layers of caching and database replication.

Used for http://support.mozilla.com
http://dev.tikiwiki.org/Performance


>  6. Editing of a subsection of a page.

http://doc.tikiwiki.org/edit+by+section


>   7. Rich content – Layout and picture heavy formatting and editing.

Tiki pages can include html


>  8. Images can be arranged in galleries and tagged. Tags from content context and user generated tags. EXIF Data?

http://doc.tikiwiki.org/Image+Gallery
http://doc.tikiwiki.org/Tags

On wish list:
http://dev.tikiwiki.org/wish1816


>   9. Rich content generated through specialized such as LaTex?

http://doc.tikiwiki.org/Mod+formula


>  10. Graphical toolbar for simplifying the process of learning the wiki/platform syntax. An interface to allow the transparent use of external editors for uploaded files and wiki pages.

http://doc.tikiwiki.org/Quicktags

>  11. Namespaces. Separation of content from discussions surrounding it, as well as personal pages about editors and users. Namespaces are prefixes before a page title (like "User:" or "Talk:") which allow a page to exist under multiple names, but serving different purposes depending on their prefix.More commonly, each page has an associated "Talk:" page which can be used to discuss its contents.

http://doc.tikiwiki.org/Wiki+Config#_User_pages
Discussions about pages can be done via threaded comments.

Please see:
http://doc.tikiwiki.org/Namespaces


>  12. Supports for user-created categories. These are similar to tags used in many web applications, but hierarchical and descriptive.

http://doc.tikiwiki.org/Tags
http://doc.tikiwiki.org/Category

Only admins can create categories and conserve the hierarchy but users can assign items to them. You could also use http://doc.tikiwiki.org/Backlinks in wiki pages as categories.


>  13. Users can configure custom JavaScript that is executed on every pageview such as tools like the "navigation popup" tool shown here displays a small preview of an article when hovering over a link title.

Sounds easy to do. If you do it, we'll add to main code base  for next version :-)


  >14. Templates that can be dynamically loaded inside another page whenever that page is requested for cases such as identifying problems with a story by putting a template in the article and this template will then output a graphical box stating that the story is disputed, and also categorize it so that articles of this nature can be located.

I am not sure what you are trying to do. This sounds like a very MediaWiki/Wikipedia way of doing things. I would think this could be done via categories or backlinks.

We also have trackers to track issues:
http://doc.tikiwiki.org/Tracker


>14.B Creating complex table layouts which are used consistently across multiple pages, and where only the content of the tables gets inserted using template parameters.

I am not sure what you are trying to do. This sounds like a very MediaWiki/Wikipedia way of doing things.

We would do this with a combination of trackers and Wiki.
http://doc.tikiwiki.org/Tracker
http://doc.tikiwiki.org/PluginTrackerList
You make a report of data in a trackers but customize the layout via a template or a wiki page.


>14b Sending users standard messages when they are blocked from editing, when their behavior is considered inappropriate, and so on.
http://doc.tikiwiki.org/Banning


>  15. User interface in different languages. A language for the wiki content itself can also be set, to be sent in the "Content-Language" HTTP header and "lang" HTML attribute.

http://doc.tikiwiki.org/i18n

> 16. Codebase should contain various "hooks" using callback functions to add additional code in an extensible way. This allows developers to write extensions without modifying the core or having to submit their code for review. Installing an extension typically consists of adding a line to the configuration file, though in some cases additional changes such as database updates are required.


What types of changes do you want to do?
http://dev.tikiwiki.org/Hello+World


>  17. Extension support for scripts to allow embedding content such as Adobe Flash files or HTML forms, ratings extension, category suggestion extension etc.

http://doc.tikiwiki.org/PluginFlash
http://doc.tikiwiki.org/Tracker  -> super powerful!
http://doc.tikiwiki.org/Rating


>  18. Performance and scalability have to be highly optimized supporting Squid caches, load balanced database replication, client-side caching, memcached or table-based caching for frequently accessed processing or query results, a simple static file cache, feature-reduced operation, revision compression, and a job queue for database operations.

Used for http://support.mozilla.com
http://dev.tikiwiki.org/Performance

You could also use TRIM to deploy and maintain hundreds of distinct installations on various servers:
http://dev.tikiwiki.org/TRIM


>  19. How do we display the translation interface?


http://doc.tikiwiki.org/i18n
http://wiki-translation.com/CLWE+Demo+Screencast -> Very nice!



>  20. Implement Lulu and Scribd API


Not to my knowledge but I suspect they make it very easy :-)


> Now I realise that this will not be an out of the box solution but my question is which wiki platform would be a good starting point for this and one that we should choose to work with and extend to integrate the functionality we are looking for?

I would say that most of it is out of the box (and as you can see, documented!)  I hope you pick TikiWiki and choose to contribute:
http://dev.tikiwiki.org/How+to+get+commit+access

Some more reading:
http://www.marclaporte.com/TikiSucks


Best regards,

M ;-)