For corporate adoption, the main thing MediaWiki needs is not some particular feature. It needs to be supported. It needs an organisation with people who will care if corporate users are screwed over by a change. It needs community management, so that the features needed by corporate users will be discoverable and well-maintained, rather than developed privately, over and over. And it needs the smallest nudge of promotion, on top of what Wikipedia fans are doing for it. Say, a nice-looking website aimed at this user base.

I was on the other side of this, albeit a while back. We had to decide between MediaWiki and Confluence to power Disney's ParentPedia (which has since been abandoned): The main reasons we chose Confluence: * An easier to understand API. This seems to not be a problem any more: http://www.mediawiki.org/wiki/API:Client_code * Easier setup on Windows: http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Windows, possibly made easier now by Bitnami: http://bitnami.org/stack/mediawiki

Yes, that is the prime reason we're still on 1.17 at work, it's the

On Thu, Feb 7, 2013 at 2:39 PM, Thomas Gries <mail(a)tgries.de> wrote: Yes, but as I mentioned until there is a suitable replacement, your choices are: run an insecure wiki, not use mediawiki.

Vistaprint (www.vistaprint.com) has a hugely successful MediaWiki system internally. 150,000+ topics, 1000+ active users across several continents, five years of history, and a fully supported team of developers to create extensions. (We are looking into open-sourcing some of them.) The main requests from our corporate users are: 0. WYSIWIG editor. No surprise here. 1. A desire for a department to have "their own space" on the wiki. I'm not talking about access control, but (1) customized look& feel, and (2) ability to narrow searches to find articles only within that space. The closest related concept in MediaWiki is the namespace, which can have its own CSS styling, and you can search within a namespace using Lucene with the syntax "NamespaceName:SearchString". However, this is not a pleasant solution, because it's cumbersome to precede every article title with "NamespaceName: " when you create, link, and search. If the *concept* of namespaces could be decoupled from its title syntax, this would be a big win for us. So a namespace would be a first-class property of an article (like it is in the database), and not a prefix of the article title (at the UI level). I've been thinking about writing an extension that provides this kind of UI when creating articles, searching for them, linking, etc. Some way to search within categories reliably would also be a huge win. Lucene provides "incategory:" but it misses all articles with transcluded category tags. 2. Hierarchy. Departments want not only "their own space," they want "subspaces" beneath it. For example, "Human Resources" wiki area with sub-areas of Payroll, Benefits, and Recruiting. I realize Confluence supports this... but we decided against Confluence because you have to choose an article's area when you create it (at least when we evaluated Confluence years ago). This is a mental barrier to creating an article, if you don't know where you want to put it yet. MediaWiki is so much better in this regard -- if you want an article, just make it, and don't worry where it "goes" since the main namespace is flat. I've been thinking about writing an extension that superimposes a hierarchy on existing namespaces, and what the implications would be for the rest of the MediaWiki UI. It's an interesting problem. Anyone tried it? 3. Tools for organizing large groups of articles. Categories and namespaces are great, and the DPL extension helps a lot. But when (say) the Legal department creates 700 articles that all begin with the words "Legal department" (e.g., "Legal department policies", "Legal department meeting 2012-07-01", "Legal department lunch", etc.), suddenly the AJAX auto-suggest search box becomes a real pain for finding Legal department articles. This is SO COMMON in a corporate environment with many departments, as people try to game the search box by titling all their articles with "Legal department"... until suddenly it doesn't scale and they're stuck. I'd like to see tools for easily retitling and recategorizing large numbers of articles at once. 4. Integration with popular corporate tools like MS Office, MS Exchange, etc. We've spent thousands of hours doing this: for example, an extension that embeds an Excel spreadsheet in a wiki page (read-only, using a $10,000 commercial Excel-to-HTML translator as a back-end), and we're looking at embedding Exchange calendars in wiki pages next. 5. Corporate reorganizations and article titles. In any company, the names and relationships of departments change. What do you do when 10,000 wiki links refer to the old department name? Sure, you can move the article "Finance department" to "Global Finance department" and let redirects handle the rest: now your links work. But they still have the old department name, and global search-and-replace is truly scary when wikitext might get altered by accident. Also, there's the category called "Finance department". You can't rename categories easily. I know you can do it with Pywikipedia, but it's slow and risky (e.g., Pywikipedia used to have a bug that killed<noinclude> tags around categories it changed). Categories should be fully first-class so renames are as simple as article title changes. Hope this was insightful/educational... DanB _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

In our organisation (CUSTIS, Russia) we easily solve it by creating one primary wiki + separate ones for different departments.

Recategorising is very simple with global search-and-replace. Our implementation is called BatchEditor https://github.com/mediawiki4intranet/BatchEditor

O_O $10000 excel-to-html? O_OOO Why not just copy-paste into for example wikEd (google://wikEd)? :-))) Not that beautiful, but it works.

also we have SemanticMediaWiki.

On 02/08/2013 01:23 PM, Daniel Barrett wrote: A recent improvement in SMW is the new database structure for Semantic MediaWiki, SMWSQLStore3 -- this makes SMW faster and more efficient. http://semantic-mediawiki.org/wiki/Semantic_MediaWiki_1.8 It got released 2 December 2012. So yeah, check it out. (Shout-out to Nischay Nahata who led that work as his 2012 Summer of Code project.) -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Now, I will demonstrate what I mean by "Corporate needs are different." :-) With our extension, the Excel spreadsheet is rendered "live" in the wiki page. So if somebody updates the spreadsheet (on a network drive), the wiki page is automatically and instantly up to date! This is totally different from a one-time copy-and-paste, and much more maintainable. (And it's pretty fast too, with AJAX and good caching.) Even better, if your spreadsheet generates a graph or chart, the image gets embedded in the wiki page too, and is automatically kept up to date. And if your spreadsheet calls out to a database for its data, to generate the chart, then the wiki is updated when the database changes too! Suddenly, MediaWiki has all the charting capability of Excel + SQL. This is very powerful and definitely worth $10K for a highly analytical company like ours. We've had this feature for about 2 months, and so far we have 350+ articles with embedded spreadsheets, updated "live."

As an aside, you could almost certainly do this cheaper with WorkingWiki. If you can write a make rule to retrieve the Excel file from the network drive and make it into html and image files (and maybe a little wikitext to format the page), you're done. LW

On 08/02/13 21:51, Lee Worden wrote: You could do it with openoffice.org/libreoffice, although I agree that getting all the dependencies right for running in the server is a bit tedious. You can also use Excel itself for that (eg. COM automation), as suggested by vitalif, supposing you are using a Windows server.

In big companies, 10 000$ is cheap. Plus I bet they get a support contract coming in. Overall, that is probably cheaper than paying an internal software developer to integrate and then maintain the WorkingWiki solution. -- Antoine "hashar" Musso

> Each department winds up writing its own wiki page about the same > topic (say, Topic X), and they're all different.

So it means most of your departments work on something very similar?

Do you have any extensions or modifications that you would like to make public & free & open source? Or maybe you even already did it with something? :-)

On 02/11/2013 11:25 AM, Daniel Barrett wrote: I find it is easier to imagine what would happen if each language had a separate Wikipedia. We would end up with slightly different facts maintained on each wiki.

On 2013-02-13 11:27 AM, "Marco Fleckinger" &lt;marco.fleckinger(a)wikipedia.at&gt; wrote: The same problem would result. the Falkland island on the English and the Spanish Wikipedia. IMHO each community should organize his wiki on it's own. Meta, Mediawiki, Commons and Wikidata already have interlanguage-communities and I think this doesn't work bad. the wikis' structures. Therefore I think that there will be discussion. So it's really great that the developers let the consumers the choice if they wanted to use wikidata or not. I think you missed the point of the previous email. -bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

IMHO there are so much useful extensions that I think it can be a little much for that page. For example if I edited that article I would put almost all extensions from our distribution there... so I'm documenting them on http://wiki.4intra.net/Category:Mediawiki4Intranet_extensions :-)

There are so many extensions useful to the enterprise but probably also so many which are not useful at all or not maintained and if I wanted to start a corporate wiki right now I would probably be very lost what to look at and how people do things, so it seemed like a good idea to list the extensions that ARE actually used. Also, I guess one team solved a certain problem one way, while another solved it differenty, using a different extension or set of extensions, so writing this out might help everybody get new ideas/ avoid reinventing the wheel. But I guess I either asked on the wrong list or there is not much interest at all.

On Thu, Feb 7, 2013 at 1:31 PM, Daniel Barrett &lt;danb(a)vistaprint.com&gt;

I assume you looked at enabling subpages in the main namespace?[1] That way Human Resources/Payroll/Show_me_the_money gets a nice breadcrumb up to Payroll and Human Resources landing pages. You can encourage people to create subpages rather than making yet another top-level page by putting [Create page] forms on landing pages that use a local template[2] and prepend the local hierarchy. > I'm not talking about access control, but (1) customized look & feel,

(1) Code could infer subpage hierarchy and apply CSS from a corresponding CSS hierarchy. (2) Add prefix: to the searches to search subpages, you can make a form for it[3].

> 1. A desire for a department to have "their own space" on the wiki.

I assume you looked at enabling subpages in the main namespace?[1] That way Human Resources/Payroll/Show_me_the_money gets a nice breadcrumb up to Payroll and Human Resources landing pages.