Hello,
As Carlos pointed out, I had accidentally hijacked an earlier thread, so I am starting this new one up. Here is the original message:
I have implemented Google Custom Search on enstage.opensuse.org, and I am personally very happy with the results. To try it out, you can visit http://enstage.opensuse.org/Portal:GoogleSearch and try searching on anything you want. It is about a thousand times better than what we have, and with the better relevance ranking, namespace searching is no longer an issue.
While the current search is advertisement supported, I am nearly positive that we can get ad support removed. It seems that Google is pretty willing to do this for non-profits.
What does everyone think? If you don't have access to the staging site, I will be more than happy to send you a screen shot of the search page.
If everyone is on board, I will ask Thomas to edit the theme to make it the default search, and we'll send it live.
Thanks,
Matt
By the way, you need access to the staging site to see this (i.e. you need to be on the Novell network). I can provide screen shots if requested.
Good Day,
So here is an update on https://bugzilla.novell.com/show_bug.cgi?id=625677. After contacting the author about the spelling suggestion issue I was having, I finally got it to work. As an added bonus, I have discovered and enabled the related articles feature as well. With these features working, Lucene is definitely a better option than Sphinx now.
All the "new" wikis on stage (en, dewiki, and languages) are now using Lucene search. The enstage wiki has the most content of the three, so you can get the best idea of how well it works by going there. However, those of you who are fluent in German should also try dewiki, so that you can see how well the search deals with German stemming and stopwords.
The indexing takes 45-50 seconds on stage, so I'm expecting it to take about a minute to index the live English wiki, and probably another 30 seconds for the production dewiki and languages. Once everything is transitioned over to the new wiki structure, total indexing will probably be in the 10 minute range. I plan to put the indexer on a daily cron, so all changes should show up in the search within 24 hours.
I am setting up a meeting with the data center to go over an OS upgrade plan so that we can get this going as soon as possible.
-Matt
Hi Guys,
I see multiple Category with colon in title. Eg. Category:SDB:Network. I feel
this is not correct, but I can't find anything in the Guidelines about it.
So what will be the guideline on this? Category should be Category:Network and
should become a sub-category of Category:SDB... right?
I discussed a few weeks ago on IRC, but I can't remember the outcome off this
and I feel it needs to be discussed with more then 1 men ;)
(I'm asking this, because there are network related topics, that do not belong
to SDB:, so forcing me to create Category:Network)
Greatings, Tim
--
To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org
I started to create basic structure that will be the same as en.opensuse.org .
Not much done this evening.
Part of main page and Help:Language_wikis.
Created interwiki links for almost all domains, but skipped few that are dead
for years, see http://languages.opensuse.org/Help:Language_wikis . There can
be more to comment out.
Tomorrow will try to reach the point to have Portal:Bulgarian as basic
navigation for all other pages in Bulgarian language. Navigation as usually in
right side vertical bar, and list of all pages in Category:Bulgarian using
CategoryTree.
Basic navigation should be:
"English title/BG" as redirect to "Translated title in Bulgarian" without any
suffix or prefix.
Not yet sure that I like / ie. subpages as place for redirects, ie. are there
any advantages to use them.
There is obligation that translator put all articles at least in
[[Category:Bulgarian]] and also [[Category:Bugarski]] (missing cyrilic
alphabet, but potential translators will get the point). Each of categories
will live in root of all translation categories [[Category:openSUSE project
languages]].
One of basic requirements for this to work is that is simple to create
translation, which can be achieved with each mandatory page containing
InputBox.
Number of mandatory pages must be real minimum, so that is easy to update
them, and they must be tracked for changes (watch list).
--
Regards,
Rajko
--
To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org
Hi all,
I'm trying to provide support on the forum. However, my browser's
connection keeps getting reset so I cannot log on. :-)
Cheers!
Roman
--
To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org
From opensuse(a)opensuse.org
> I'm sure this issue has come up before (found several references in
> google, all with URLs that point into oblivion since changes. e.g.
> http://en.opensuse.org/VirtualBox_installation)
Just logging this since I have time for that much. If some kind soul
would put in yet another redirect or copy the page? Or I may get to it
myself sometime, just wanted it recorded.
--
bkw
--
To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org
>> I have installed both Sphinx and Lucene on the staging sites. They
>> each have their advantages and disadvantages, so I want to see what
>> everyone would like to see go to production.
>
>I know that sphinx might be tempting right now but i would definitely go
>with lucene. Because we can then live off the development and
>maintenance of mediawiki instead of doing our own. I also think we
>should use the same style as the mediawiki search page because people
>are used to it.
Yes, I agree that that the search integration bothers me too. If Sphinx had the same quality of plugin as MWSearch, then I would be much more convinced that it is better choice for us. As it is right now, I suppose it's something of a coin toss.
One option is to rework the plugin to integrate with the default search functions instead of working around them. This shouldn't be as hard as it sounds. The vast majority of this would be in a single PHP file, and I don't think it would take more than a couple of hours. I could do it myself if I wasn't so swamped by other requests. The default search and both search extensions are hardly ever updated, there wouldn't be much work once this is done. Anyways, it's just a thought.
One of my main concerns for Lucene are that the indexing process is very heavy, so I wouldn't want to run it more than once or maybe twice a day, compared to every few minutes for Sphinx. There is a way to do incremental updates, but it involves yet another extension and schema change, and there have been numerous problems reported with it.
The other big concern is that I cannot get suggestions to work at all under Lucene. The spelling index gets created, but I cannot get the search daemon to use it. I'm going to try compiling the Java source under the system's JDK and Ant to see if that gets me anywhere. If I can get the suggestion functionality to work, then I will agree that Lucene is absolutely the superior choice (their suggestion functionality beats aspell/pspell hands down).
Hello,
I have installed both Sphinx and Lucene on the staging sites. They each have their advantages and disadvantages, so I want to see what everyone would like to see go to production. Here is a quick rundown of the advantages of each:
Lucene:
-Better integration with MediaWiki default search
-Displays the custom "No results" message that Henne created if no results are found (Sphinx can probably be hacked to do this without too much trouble)
-Slightly better relevance on some queries
-Displays word count and timestamp for each result (some hacking can probably get this on Sphinx as well)
Sphinx:
-More frequent indexing possible (full indexing daily with incremental indexing every few minutes)
-Written in C, no Java installation required
-Because of the above, it can be moved live without having to wait on an OS upgrade
-Spell checking through aspell (Lucene's is supposedly better, but I cannot get it to work at all)
-Easier to customize the extension and better documentation
Both search options are extremely fast, provide highly relevant results, support wildcard searches, and work well with multiple wikis (including language specific stemming). Needless to say, both are far superior to the default search. I am slightly more in favor of Sphinx right now. This is partly because it is easy to hack the extension, and partly because it could go live tomorrow if we want to.
For those of you who can get to the staging site, Lucene is set as the default search, and Sphinx can be found at stage.opensuse.org/Special:SphinxSearch. Feel free to try them out and compare.
-Matt
--
To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org
Hello all,
Up here in Brazil, we are working together with some guys from Portugal to improve and grow our openSUSE Portuguese language community in quality and numbers and one of our next steps is to make our Portuguese wiki page more aligned with the global wiki page. Then we believe we need no more than 3 users with full rights at http://pt.opensuse.org/MediaWiki:Mainpagerightcolumn to be able to migrate our wiki theme to "bento" for example. Is this possible? Makes sense?
Also, As I mentioned we like to migrate our wiki theme to "bento" Any clue who is the best one to give a hand to us? Is there anything we must do before this process happen?
best regards
thanks
CarlosRibeiro
--
To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org
Hello,
In preparation for the 1.16 upgrade and installing the latest Lucene search, the data center has created a new virtual machine with the latest and greatest version of SLES. Over the next few days, I will be setting up this new machine and transferring content, after which we will change the iChain configurations to point to the new stage server.
Please make sure to inform me if you are doing anything on the current staging box, as your changes could otherwise be lost. I will inform you when the changes are all done, hopefully sometime next week.
-Matt
