On 16/06/13 05:43, Brian Wolff wrote:
On 6/16/13, Tyler Romeo tylerro...@gmail.com wrote:
It's 10 times slower than doing === null, which is a bit trivial in
context, but nonetheless a fact, and it's also a bit easier to read,
especially when doing the inverse (i.e., doing !is_null( ... )
Hey,
On the colour of the bikeshed: !== generally reads better then !is_null.
$foo is not null vs is not null $foo.
I however object against constructing this shed in the first place. Seems
like a waste of good mental effort, on which some much nicer buildings can
be constructed.
Cheers
--
No, DXR doesn't help the CSE. I also doubt it will help restoring full
text search on our end, but we'll see.
https://bugzilla.wikimedia.org/show_bug.cgi?id=49674
On the contrary, gitblit is more robust and faster than gitweb, so it
allows crawling by search engines. It was crawled very
I disagree with the last three messages: the visual editor is bound to
be painful when enabled; if the team has established that they're in a
stage where they are done with the knowns in some areas but need more
testing on the field (and feedback) to discover more, they must be
allowed to,
Federico Leva (Nemo) wrote:
I disagree with the last three messages: the visual editor is bound to
be painful when enabled; if the team has established that they're in a
stage where they are done with the knowns in some areas but need more
testing on the field (and feedback) to discover more, they
Can you explain how to set a user preference based on the number of edits
a new user has? Has the VisualEditor team set up a script to roll back
(i.e., undo) this change to the user preferences of new users if this
experiment doesn't work well? Personally, I think it would be a little
crazy to
The fact that there are known issues doesn't mean that finding new,
unknown issues will slow down the work on the known; it's up to the team
to decide what sort and what amount of feedback they'll be able/need to
process (and to adjust if they were wrong).
Gradually enabling a feature is not
Thanks to Matt and Daniel for your input so far.
I would really appreciate some more heads commenting/voting on this so
it is possible to start building this...
Thanks in advance!
Jon
https://mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates
On Thu, Jun 13, 2013 at 2:05 PM,
Turning back to the automating thing and the Main Page.
I've got tired updating the Other Wikipedias section (congratulations to
the Swedish Wikipedia!), so I wrote some code to automate the job.
There is a bot that updates different statistics per wiki. I decided to
parse the data page and push
On 2013-06-17 4:20 PM, Paul Selitskas p.selits...@gmail.com wrote:
Turning back to the automating thing and the Main Page.
I've got tired updating the Other Wikipedias section (congratulations to
the Swedish Wikipedia!), so I wrote some code to automate the job.
There is a bot that updates
See the full Roadmap at:
http://www.mediawiki.org/wiki/Roadmap
And the diff for this last update:
http://www.mediawiki.org/w/index.php?title=Roadmapdiff=711356oldid=711338
Highlights:
= Search =
* With the new search engineer on board, Nik, working with Chad on
search the current plan for
https://www.mediawiki.org/wiki/Requests_for_comment/CirrusSearch
This made me realize I have a poor sense of the features in search, so I
read the documentation.
http://www.mediawiki.org/wiki/Help:Searching is bare-bones, and
https://en.wikipedia.org/wiki/Help:Searching disagrees. Perhaps
On Mon, Jun 17, 2013 at 1:28 PM, S Page sp...@wikimedia.org wrote:
* enwiki says Hello dolly in quotes gives different results, mw directly
contradicts this. Even on my local wiki, quotes make a difference.
* enwiki disagrees with itself what a dash in front of a word does.
I did some
Le 04/06/13 18:00, Antoine Musso a écrit :
Hello,
Since we introduced hooks in MediaWiki, the documentation has been
maintained in a flat file /docs/hooks.txt . Over the week-end I have
converted the content of that file to let Doxygen recognize it.
The patchset is:
I'm not sure about http://www.mediawiki.org/wiki/Help:Searching but
https://en.wikipedia.org/wiki/Help:Searching has lots of things we're going
to have to add to our list. My guess is
http://www.mediawiki.org/wiki/Help:Searching is simply out of date.
Nik
On Mon, Jun 17, 2013 at 4:33 PM, Chris
On 06/13/2013 01:07 PM, Quim Gil wrote:
Dear GSoC mentors:
Here is a heads up about the GSoC Mentor Summit:
https://www.mediawiki.org/wiki/Talk:Mentorship_programs/Possible_mentors#GSoC_Mentor_Summit
Nobody signed up? I'm sure we can fill the 2 seats only with WMF
employees based in San
Just as a note, MediaWiki default (aka crappy) search is very
different from the lucene stuff used by Wikimedia. Lucene search is
rather difficult to set up, so most third party wikis do not use it.
--bawolff
On 6/17/13, Nikolas Everett never...@wikimedia.org wrote:
I'm not sure about
One of our goals while building this has been to make something reasonably
easy to install by folks outside of WMF. I've added some notes about this
to the page. I'd certainly love to hear ways that'd make it simpler to use.
Nik
On Mon, Jun 17, 2013 at 8:23 PM, Brian Wolff bawo...@gmail.com
Hi,
The interest of the VE team is not the only one to take into account I
think...
The impact on the new wikipedia editors should be a more important
parameter in my opinion.
I tried VE a few times, and clearly think it's not yet in a situation where
it could be rolled out to unexperienced
I think that from user perspective, such help pages are not very useful
since most users don't read help pages.
Some features (the important ones) should be hinted in the search form
itself.
In hewiki we modified the [[MediaWiki:Search-summary]][1] to include a
small expandable table with hints
20 matches
Mail list logo
