Instead of having all the communities on the same MediaWiki wiki separated by page names, you can run multiple wikis off one MediaWiki installation. At Brickimedia (see http://www.mediawiki.org/wiki/Brickimedia) each wiki runs off one MediaWiki installation and just loads a different LocalSettings file and a different database based on what subdomain is typed in. This requires some extra apache/nginx configuration but if you take a look here you might understand it: https://github.com/Brickimedia/LocalSettings/blob/master/LocalSettings.php#L81-L183
On Mon Feb 02 2015 at 9:00:48 PM Jay R <[email protected]> wrote: > Thank you for your thoughts! Our projects are definitely different but its > still nice to know that someone is trying to make something positive. > I will have to get help about what to do next. > > Jay > > > On Mon, Feb 2, 2015 at 7:10 AM, JFC Morfin <[email protected]> wrote: > > > At 00:26 02/02/2015, Jay R wrote: > > > >> I've been creating a job description for making a non-profit ad-free > >> website which will allow people to setup their own communities where > they > >> can work on solving problems relating to specific areas. Different tools > >> will be provided to them including a custom-built task management > system, > >> a > >> forum and a wiki. > >> > > > > I am working on a similar Libre concept I call a cyberagora. > Unfortunately > > in French (http://cybagora.org). > > The idea is the smartest conviality afficient support of "agoras" > (cities, > > wg, communities, personal windows to the world, mathematical concept, > etc.) > > > > The whole website will be "wiki" based i.e., people will collaboratively > >> work together and edit task items which are not Wiki pages. For example > it > >> may be a row in a database of another table. > >> > > > > My idea is of a flexible federation of SQLite based mediawikis (as a > > start), and eventually a cloud of "intellipages" (i.e. smart independent > > json based wikipages) virtually gathered together through a DDDS ( > > http://en.wikipedia.org/wiki/Dynamic_Delegation_Discovery_System).. This > > way I have no hosting to consider and maximum flexibility. > > > > Anyone can fill out a form and a new community is created along with a > >> wiki > >> of their own. So each community will have access to its own set of wiki > >> pages. They may have 5 or 20 or 100 pages. In the long term there may be > >> 100's or 1000's of communities if the website is a success. The URL of > a > >> wiki could be something like: en.Solveissues123.org/Community6543/Wiki > >> <http://en.Solveissues.org/Community6543/Wiki> > >> The issues are: > >> (1) User database. I'd like to keep a common user database so people can > >> login once and edit other community wikis. > >> > > > > I suggest a different approach: by capacities. Can access an intellipage > > only those with the necessary capacity. They acquire the capacities > through > > a DDDS service (like the DNS) for a limited duration. > > > > (2) Interlinking between various wiki communities > >> (3) Sidebar content for each community so they have their own > navigation. > >> (4) Communities may be set up in their own language so a wiki may have > >> its own language. > >> (5) There may be customization for aesthetics. > >> > > > > OK for all of this. This is part, from my POV, of the VGN (Virtual Glocal > > Network) contextual parametring (the participating sites to a relational > > space). > > > > My idea is as follows: > > - the intellipages follows a common formating JSON standard. > > - they are registered by their owner in one or several relational spaces > > - these relational spaces are supported by people's VGN with their local > > global or global local constraints (like a format, verification tools, > > Quality control; langages, etc.). > > > > It will be like Wikia but I have to reserve the sub-domains for > languages. > >> I want to use Mediawiki and it will have to be customized to a large > >> extent. > >> I have different options: > >> > >> 1. Use one Mediawiki for the whole website (so one database). Let people > >> separate their community wikis by using different page titles for > example > >> [[Community6543/Title of Page]]. They would have to use a similar > notation > >> to keep their categories separate. There will be one user database so > >> that's good since anyone can edit a page from any community. > >> The issue are the sidebar and other navigational links and language > >> options. I could get the installation fully customized and change it so > >> they need to edit [[Community6543/Sidebar]] to show their own > navigation. > >> > >> 2. Use one mediawiki for each community. They can all use the same user > >> database ($wgSharedDB). Not sure how to manage interlinking here. Any > >> other > >> issues I need to think about? This may be a good solution since a > >> community > >> may have its own language. > >> > >> 3. Use a 3rd light weight wiki software that provides basic wiki > functions > >> (editing, page history, diffs). Is there anything like that available or > >> would it need to be created from scratch? > >> > > > > This is a good question :-) > > The best would be syntaxic/use compatibility with wikipedia. So the best > > products of the personal/group wikis could be copied to wikipedia. > > > > A sidenote: Any general advice on how to manage the individual forum > >> creation as well? I would not like to use the talk pages as forums but > >> rather an independent traditional forum for each community. > >> > > > > IMHO you need everything you can findimagine (blogs, mailing list, fora, > > heuristic maps, etc.) and be totally language independent (except js as > the > > bowsers' language). > > > > Any advice would be appreciated. Or if you know where I can get > >> professional help in creating the job description for this website let > me > >> know. I can then post the job at a freelancing website to have the > website > >> made. > >> > > > > Not so easy. I would advise for each tool to look first at all the > > parameters being supported (mediawiki, wordpress, etc.) to make sure you > do > > not forget any of them. Then to compare them from one tool to another and > > establish your own common parameter tables. Then review each > functionality > > in a multiple tools context, to see what can be aggregated or extended. > > > > From there you will need to design a system architecture taking care of > > replications/security/backup/restorations and of the mix of the > different > > databases (DDDS, Semantics) included. At the same time you need to > imagine > > how you can make it commercial (business and non-profit alike) and > support > > extensions by third parties (API). > > > > Then, not so much to write a job desciption, but a protocol, like an RFC. > > Then to start with a prototype, and test it. Then to add foreseen and new > > features you will have discovered from experimentation. > > > > Just half a cent, for a big project. > > jfc > > > > > > Jay > >> _______________________________________________ > >> MediaWiki-l mailing list > >> To unsubscribe, go to: > >> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > >> > > > > > > _______________________________________________ > > MediaWiki-l mailing list > > To unsubscribe, go to: > > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > > > _______________________________________________ > MediaWiki-l mailing list > To unsubscribe, go to: > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
