Hello,
My name is Anthony and I'm looking at possible replacement for my organization's current document management system: Foswiki.
I've looked at a number of different comparison charts and spoke to a few vendors, but have hadtrouble actually getting a good sense for what might work for us. Here are a few things that our users are looking to find, in the new system:
* Have search results return page headings or other recognizable entity title. * Be able to group or un-group search results by web/category/areas * Search results show context of search term or at least show highlighted search term in a section of the result. * Search results focus page on the results not fill the page with fluff * Search results are ranked. Not all hits should be treated equally. * Tool is easy to navigate through contents/menus to appropriate page * Adding new entries is intuitive and easy to accomplish. * Editing existing entries is intuitive and easy to accomplish. ** Provide options/support for importing existing (FOS Wiki) data.
Anyone out there who knows Mediawiki well enough to speak to the question of how it addresses the above, please let me know your thoughts.
Thank you,
-Anthony
TL;DR: Please add feedback to
<https://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_integrated>
Since MediaWiki 1.20 has been released, a discussion (opened by hexmode)
is ongoing on how to make our release notes better so that users
understand what improvements there are and why they should update:
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/65080
(please join if you didn't yet).
Another problem, however, is making the tarball, which is what most
sites use, actually useful. After the first in 1.18, no more extensions
have been bundled: Wikimedia projects use no less than 140 extension
(most of them functioning) but the tarball ships only 7.
A problem that many MediaWiki users have is that they don't understand
how vital many extension are, at least for any wiki open to the web.
I'd like 1.21 to include some more, so I ask you to join the
brainstorming on our good old
<https://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_integrated>
There are already a few suggestions on it; my personal pet peeve is that
MediaWiki is perhaps the software with the best localisation existing
but very few use it well because we don't ship LocalisationUpdate.
Topic for another discussion would be to solve some problems with the
installer/upgrader like "set up cron for TorBlock" (?) or "check the
compatibility of extensions"...
Nemo
-------- Messaggio originale --------
Oggetto: [Mediawiki-i18n] MediaWiki Language Extension Bundle launches
Data: Wed, 28 Nov 2012 12:17:20 +0200
Mittente: Niklas Laxström
A: MediaWiki internationalisation <mediawiki-i18n(a)lists.wikimedia.org>
The Wikimedia Language Engineering team is pleased to announce the
first release of the MediaWiki Language Extension Bundle. The bundle
is a collection of selected MediaWiki extensions needed by any wiki
which desires to be multilingual.
This first bundle release (2012.11) is compatible with MediaWiki 1.19,
1.20 and 1.21alpha.
Get it from https://www.mediawiki.org/wiki/MLEB
The Universal Language Selector is a must have, because it provides an
essential functionality for any user regardless on the number of
languages he/she speaks: language selection, font support for
displaying scripts badly supported by operating systems and input
methods for typing languages that don't use Latin (a-z) alphabet.
Maintaining multilingual content in a wiki is a mess without the
Translate extension, which is used by Wikimedia, KDE and
translatewiki.net, where hundreds of pieces of documentation and
interface translations are updated every day; with Localisation Update
your users will always have the latest translations freshly out of the
oven. The Clean Changes extension keeps your recent changes page
uncluttered from translation activity and other distractions.
Don't miss the chance to practice your rusty language skills and use
the Babel extension to mark the languages you speak and to find other
speakers of the same language in your wiki. And finally the cldr
extension is a database of language and country translations.
We are aiming to make new releases every month, so that you can easily
stay on the cutting edge with the constantly improving language
support. The bundle comes with clear installation and upgrade
installations. The bundle is tested against MediaWiki release
versions, so you can avoid most of the temporary breaks that would
happen if you were using the latest development versions instead.
Because this is our first release, there can be some rough edges.
Please provide us a lot of feedback so that we can improve for the
next release.
-Niklas
--
Niklas Laxström
_______________________________________________
Mediawiki-i18n mailing list
Mediawiki-i18n(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
On Thursday, November 29th, between 21:00-22:00 UTC (1-2pm PST)
Wikimedia Foundation will release security updates for current and
supported branches of the MediaWiki software. We are providing this
pre-announcement as a courtesy for administrators to be ready to
accept the fix for these on Thursday. We will send another
announcement email when the patches and tar files are ready for
download.
* Vulnerabilities were found in both MediaWiki core and the
CentralAuth extension. Successful exploitation could allow an attacker
to compromise another user's account. Risk is considered moderate
(CVSS Base Score: 4).
* One vulnerability was discovered that could allow an attacker to
prevent users from viewing Special:RecentChanges, and other pages,
which could prevent the detection of SPAM or vandalism. Public wikis
are encouraged to upgrade.
* A flaw in the MediaWiki 1.20 API could allow a stored XSS.
Exploitation requires user interaction or an existing XSS
vulnerability, so risk of exploitation is low.
For information about how to upgrade, see
<https://www.mediawiki.org/wiki/Manual:Upgrading>
Going back to your mention of preapproving edits - would it be straightforward to have an extension hook check to see if a certain "protected" section was edited by comparing it to the previous revision?
________________________________
From: Arcane 21 <arcane(a)live.com>
To: alj62888(a)yahoo.com
Sent: Tuesday, November 27, 2012 11:36 AM
Subject: RE: [MediaWiki-l] Forcing a certain page layout
Unfortunately, MediaWiki doesn't have a selective page portions protection scheme as far as I'm aware, and I've dabbled with a few other types of wiki software and haven't found a way to do this as well.
The best thing you can do (in MediaWiki) is using the template scheme I suggested, and protecting the rest of the page (don't enable cascade protection if you do this). The edit links on the page will lead to the subpage links that can be edited, and they will display that information on the main page without changing the rest of the protected content.
> Date: Tue, 27 Nov 2012 10:29:44 -0800
> From: alj62888(a)yahoo.com
> To: mediawiki-l(a)lists.wikimedia.org
> Subject: Re: [MediaWiki-l] Forcing a certain page layout
>
> Thanks Arcane, you touched on another question I had; protecting certain portions of a page from edit. Is there seriously no way to do this at all that isn't a hack? This would be a deal-breaker, unfortunately. Any suggestions for other wikis?
>
> Thanks,
> Al
>
>
>
> ________________________________
> From: Arcane 21 <arcane(a)live.com>
> To: alj62888(a)yahoo.com
> Sent: Tuesday, November 27, 2012 11:08 AM
> Subject: RE: [MediaWiki-l] Forcing a certain page layout
>
>
>
> I've dabbled with SMW and infoboxes in the past, and I don't think there is an option to "lock" a certain part of the page in place.
>
> However, you do have two options you might try: First, you could set it up to where revisions have to approved, and you can reject revisions that relocate the infobox. Second, you could have the edit link for the infobox template redirect to a subpage of the main page that can be edited, and the finished product appears in the infobox.
>
> The second option requires the infobox be a template with an automatic redirect to an editable subpage, but that shouldn't be too difficult to set up.
>
> Unfortunately, I'm not aware of any means of protecting portions of a page instead of the whole page.
>
>
> > Date: Tue, 27 Nov 2012 09:38:09 -0800
> > From: alj62888(a)yahoo.com
> > To: mediawiki-l(a)lists.wikimedia.org
> > Subject: [MediaWiki-l] Forcing a certain page layout
> >
> > Hi, this is a newbie question; thanks in advance.
> >
> > I'm thinking about using SMW with MW. I'll use Semantic Forms and the like to make entering the semantic data easier and then let editors enter free text for other miscellaneous sections. But, the semantic stuff is the most important and I want to make sure the semantic data section is always on a particular location on the page; say, the top. I don't want an editor to relocate the info box anywhere he wants. Is this possible?
> >
> > Thanks,
> > Al
> > _______________________________________________
> > MediaWiki-l mailing list
> > MediaWiki-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Thanks Arcane, you touched on another question I had; protecting certain portions of a page from edit. Is there seriously no way to do this at all that isn't a hack? This would be a deal-breaker, unfortunately. Any suggestions for other wikis?
Thanks,
Al
________________________________
From: Arcane 21 <arcane(a)live.com>
To: alj62888(a)yahoo.com
Sent: Tuesday, November 27, 2012 11:08 AM
Subject: RE: [MediaWiki-l] Forcing a certain page layout
I've dabbled with SMW and infoboxes in the past, and I don't think there is an option to "lock" a certain part of the page in place.
However, you do have two options you might try: First, you could set it up to where revisions have to approved, and you can reject revisions that relocate the infobox. Second, you could have the edit link for the infobox template redirect to a subpage of the main page that can be edited, and the finished product appears in the infobox.
The second option requires the infobox be a template with an automatic redirect to an editable subpage, but that shouldn't be too difficult to set up.
Unfortunately, I'm not aware of any means of protecting portions of a page instead of the whole page.
> Date: Tue, 27 Nov 2012 09:38:09 -0800
> From: alj62888(a)yahoo.com
> To: mediawiki-l(a)lists.wikimedia.org
> Subject: [MediaWiki-l] Forcing a certain page layout
>
> Hi, this is a newbie question; thanks in advance.
>
> I'm thinking about using SMW with MW. I'll use Semantic Forms and the like to make entering the semantic data easier and then let editors enter free text for other miscellaneous sections. But, the semantic stuff is the most important and I want to make sure the semantic data section is always on a particular location on the page; say, the top. I don't want an editor to relocate the info box anywhere he wants. Is this possible?
>
> Thanks,
> Al
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Hello,
After extensively searching the internet, I have been unable to find out how to put a line of text above/below the usual links in the footer (Terms of Service, About, etc.). This would be a line of plain text visible on every page. Imagine it saying something like "This wiki is for X-specific use by Y-specific people" or some such jazz.
I would like to be able to add a line of plain text visible at the bottom of every page.
I am running version 1.19.1
Thank you for the help, it is much appreciated.
Hello everyone,
I've been lookng the parserFunctions extension, and other extension that
provide parser funtions over strings.
I a way to get the number of occurrences of a character in a string. Is
there any funtion for this that I missed? or should I use the variables
extension?
Thanks in advance,
Marcelo.