Re: [Wikitech-l] Status of the new PDF Renderer

[Liangent]

I didn't look at the new renderer carefully, but I guess it's a
Parsoid-based one. Hope that the language conversion syntax issue in PDF
output can be resolved together with Parsoid in the future, which blocks
the deployment of PDF output on zhwiki currently. See
https://bugzilla.wikimedia.org/show_bug.cgi?id=34919 .

-Liangent


On Fri, Jan 24, 2014 at 2:38 AM, Matthew Walker wrote:

> Marco,
>
> Is it also possible to set this up behind a firewall?
>
> Yes; with the caveat that your wiki must be running Parsoid. It is also
> theoretically possible to still use Print on Demand services behind a
> firewall as we can POST a zip bundle to them -- likely however you'd just
> disable that functionality and I'm not sure our new bundle format is
> entirely compatible with the old bundle format...
>
> If you want to set this up locally; I can help with that if you jump on IRC
> #mediawiki-pdfhack on freenode. I'm mwalker.
>
> ~Matt Walker
> Wikimedia Foundation
> Fundraising Technology Team
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit upgrade Tuesday

[C. Scott Ananian]

Will the default UI change after the upgrade?  I've grown quite used
to the current way Gerrit looks.  gerrithub (for instance) has the
"New Screen" as the default diff view, which I found very
disorienting.  (If the Server default does change, you can change it
back under Preferences > Change View > Old Screen.)
  --scott

On Fri, Jan 24, 2014 at 8:18 PM, Chad  wrote:
> All,
>
> I'm planning to upgrade Gerrit from our 2.7-rc2 custom build to the 2.8.1
> stable release on Tuesday from 01:00 to 03:00 UTC (that's 17-19:00 in
> SF on Monday evening).
>
> This will result in some minor downtime while the database is upgraded.
> I don't anticipate it to take the full 2 hour window, but I'm being cautious
> because Gerrit.
>
> -Chad
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
(http://cscott.net)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] TitleValue

[Daniel Kinzler]

Am 24.01.2014 16:15, schrieb Tim Starling:> On 24/01/14 15:11, Jeroen De Dauw 
wrote:
> Daniel proposed an ideal code
> architecture as consisting of a non-trivial network of trivial classes
> -- a bold and precise vision. Nobody was uncivil or deprecating in
> their response.

This idea is something that grew in my mind largely through discussions with
Jeroen, and the experience with the code he wrote for Wikidata. My gut feeling
for the right balance of locality vs. separation of concerns has shifted a lot
though that experience - in the beginning of the Wikidata project, I was a lot
more skeptical of the idea of "separation of concerns". Which doesn't mean I
insist of going down that road all the way all the time now.

I would like to take this opportunity to thank Jeroen for his conviction and the
work he has put into showing that DI and SoC actually make work with a big code
base less cumbersome. Without him, we would have copied more problems present in
the core code base.

One big advantage I want to highlight is confident refactoring: if you have
good, fine grained unit tests, it's easier to make large changes, because you
can be confident not to break anything.

Am 24.01.2014 14:44, schrieb Brad Jorsch (Anomie):
> It looks to me like the existing patch *already is* getting too far into
> the Javaification, with it's proliferation of classes with single methods
> that need to be created or passed around.

There is definitely room for discussion there. Should we have separate
interfaces for parsing and formatting, or should both be covered by the same
interface? Should we have a Linker interface for generating all kinds of links,
or separate interfaces (and/or implementations) for different kinds of links?

I don't have strong feelings about those, I'm happy to discuss the different
options. I'm not sure about the right place for that discussion though - the
patch? The RFC? This list?

Am 24.01.2014 15:56, schrieb Tim Starling:> On 24/01/14 11:19
> The existing patch is somewhat misleading, since a TODO comment
> indicates that some of the code in Linker should be moved to
> HtmlPageLinkRenderer, instead of it just being a wrapper. So that
> would make the class larger.

Indeed. HtmlPageLinkRenderer should take over much of the functionality
currently implemented by Linker. The implementation is going to be non-trivial.
I left that for later in order to keep the patch concise.

-- daniel





___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Gerrit upgrade Tuesday

[Chad]

All,

I'm planning to upgrade Gerrit from our 2.7-rc2 custom build to the 2.8.1
stable release on Tuesday from 01:00 to 03:00 UTC (that's 17-19:00 in
SF on Monday evening).

This will result in some minor downtime while the database is upgraded.
I don't anticipate it to take the full 2 hour window, but I'm being cautious
because Gerrit.

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] TitleValue

[Tim Starling]

On 24/01/14 15:11, Jeroen De Dauw wrote:
> Java is a technology with strong and weak sides, like any other.
> Religiously labeling anything that resembles something from it as evil
> because you do not like it is perhaps not the most constructive approach
> one can take. That is quite obvious of course. From my vantage point, it
> definitely seems like a lot of this is going on in the MediaWiki community
> with regards to this topic and several others. Do you think this is not the
> case - good for you. It is however the reason I am very reluctant to join
> any such discussions, and I know this is the case for many other people as
> well.

I think the term "javaification" was introduced to the discussion by
Nik, who is the Java developer working on CirrusSearch, as a kind of
joking self-deprecation. I don't think anyone intended to imply that
everything to do with Java is bad. Daniel proposed an ideal code
architecture as consisting of a non-trivial network of trivial classes
-- a bold and precise vision. Nobody was uncivil or deprecating in
their response.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] RFC: assertion of pre- and postconditions

[Daniel Kinzler]

RFC: https://www.mediawiki.org/wiki/Requests_for_comment/Assert

This is a proposal for providing an alternative to PHP's assert() that allows
for an simple and reliable way to check preconditions and postconditions in
MediaWiki code.

The background of this proposal is the reoccurring discussions about whether
PHP's assert() can and should be used in MediaWiki code. Two relevant threads:

http://www.gossamer-threads.com/lists/wiki/wikitech/275737
http://www.gossamer-threads.com/lists/wiki/wikitech/378676

The outcome appears to be that

assertions are generally a good way to improve code quality
but PHP's assert() is broken by design

Following a suggestion by Tim Starling, I propose to create our own functions
for assertions.

-- daniel

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] TitleValue

[Tim Starling]

On 24/01/14 11:19, Nik Everett wrote:
> The TitleValue proposal is an improvement over what we have now so I figure 
> we should just do it.  Is that ok?

I am also personally in favour of it, but I would like to achieve
consensus of the MediaWiki core team if possible before continuing.

On 24/01/14 14:44, Brad Jorsch (Anomie) wrote:
> It looks to me like the existing patch *already is* getting too far into
> the Javaification, with it's proliferation of classes with single methods
> that need to be created or passed around.

The existing patch is somewhat misleading, since a TODO comment
indicates that some of the code in Linker should be moved to
HtmlPageLinkRenderer, instead of it just being a wrapper. So that
would make the class larger.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] TitleValue

[Jeroen De Dauw]

Hey,

Java is a technology with strong and weak sides, like any other.
Religiously labeling anything that resembles something from it as evil
because you do not like it is perhaps not the most constructive approach
one can take. That is quite obvious of course. From my vantage point, it
definitely seems like a lot of this is going on in the MediaWiki community
with regards to this topic and several others. Do you think this is not the
case - good for you. It is however the reason I am very reluctant to join
any such discussions, and I know this is the case for many other people as
well.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] TitleValue

[Brad Jorsch (Anomie)]

On Fri, Jan 24, 2014 at 11:19 AM, Nik Everett wrote:

> At the architecture summit yesterday we had a conversation about the
> TitleValue proposal and the vast majority of folks thought it was a great
> start. Something like 10% of us thought the patch _might_ be a start down
> the path to Javaify MediaWiki.  I was one of the 10%.
>
> We resolved to talk more about the commit before merging it because of the
> objections of our minority. I felt somewhat vindicated. I slept on it. Now
> I don't think we made the right choice.  I think more discussion is a waste
> of time and we should just keep moving and try to catch the Javaification
> if it starts creeping in.
>

I'm disappointed, I thought you'd be our person to watch for the
Javaification.

It looks to me like the existing patch *already is* getting too far into
the Javaification, with it's proliferation of classes with single methods
that need to be created or passed around.


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Let's improve our password policy

[Steven Walling]

Hi everyone,

For some time now we've had two Requests for Comment floating around
related to passwords, neither of them making much progress.

One is the older "password strength" RFC which proposed creating a module
to tell users about the strength of their passwords. The second, "Password
requirements", had some discussion but wasn't reaching consensus and
implementation.

After proposing it about a month ago, I've merged these two RFCs and
refactored them in to
https://www.mediawiki.org/wiki/Requests_for_comment/Passwords, partially
based on feedback from Chris Steipp.

Please comment. I've tried to sharpen the proposals down in to one thing we
can do _right now_ which will do the most good for the most users. However,
there are several other viable ideas which merit discussion and example
implementations.

Thanks!

Steven
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Non-complicated way to display configuration for a given wiki?

[Tim Landscheidt]

Nathan Larson  wrote:

> [...]

> Are you saying you want to display the settings for your own wiki or
> someone else's wiki (whose backend you can't access)? If it's your own
> wiki, you can use
> ViewFilesto let
> people access a special page that will display a configuration file.

No, I meant the repository where the MediaWiki configuration
of the Wikimedia cluster resides
(cf. http://git.wikimedia.org/summary/?r=operations/mediawiki-config.git),
and I want to display the settings of one of many configured
wikis.

My use case at hand is the migration of wiki.toolserver.org
to WMF.  The former uses a traditional LocalSettings.php,
and I want to test whether a patch to
operations/mediawiki-config results in an equivalent config-
uration.

Tim


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] TitleValue

[Siebrand Mazeland (WMF)]

On Fri, Jan 24, 2014 at 11:19 AM, Nik Everett wrote:

> At the architecture summit yesterday we had a conversation about the
> TitleValue proposal and the vast majority of folks thought it was a great
> start. Something like 10% of us thought the patch _might_ be a start down
> the path to Javaify MediaWiki.  I was one of the 10%.
>
> We resolved to talk more about the commit before merging it because of the
> objections of our minority. I felt somewhat vindicated. I slept on it. Now
> I don't think we made the right choice.  I think more discussion is a waste
> of time and we should just keep moving and try to catch the Javaification
> if it starts creeping in.
>

Thank you for reconsidering, Nik. I fully support your proposal. The
concern obviously remains valid, and with all of our eyeballs on the code
and pre-merge review, we should be able to prevent disasters.

Cheers!

Siebrand
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] TitleValue

[Nik Everett]

At the architecture summit yesterday we had a conversation about the TitleValue 
proposal and the vast majority of folks thought it was a great start. Something 
like 10% of us thought the patch _might_ be a start down the path to Javaify 
MediaWiki.  I was one of the 10%.

We resolved to talk more about the commit before merging it because of the 
objections of our minority. I felt somewhat vindicated. I slept on it. Now I 
don't think we made the right choice.  I think more discussion is a waste of 
time and we should just keep moving and try to catch the Javaification if it 
starts creeping in.  

The TitleValue proposal is an improvement over what we have now so I figure we 
should just do it.  Is that ok?

In the mean time, mostly to humor me, does anyone want to start a list on wiki 
of some of the Javaification things they are scared of?  I promise to 
contribute some paranoid ramblings which we can debate on the wiki or mailing 
list. 

Thanks,

Nik
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] !ask

[Platonides]

On 20/01/14 08:26, Petr Bena wrote:

There is one more feature available on wm-bot.

First of all, that thing is smart enough to recognize who is irc
newbie and who is not. It is possible to direct this only to people
who are known to the bot (their cloak is trusted) so that it doesn't
bite the newbies, but rather "slap" the experienced who keep bad
habits. The bot is able to recognize what is a "question if they can
ask" and automatically tell the person to ask the question instead of
asking if they can ask, for example:


+1
That was precisely what I was going to propose: that the bot should 
recognise the original question and answer it itself.
I don't think there's anything wrong in getting a bot inviting  you to 
answer. And will be much nicer than having a human tell the bot to 
explain you that you can ask :)


Frankly, the reason to do !ask | foobar is basically to avoid looking up 
the appropiate template.



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Non-complicated way to display configuration for a given wiki?

[Tim Landscheidt]

I wrote:

> [...]

> However, all my creativity regarding parameters to getAll()
> only returned an empty array.

> What would be the parameters needed for example to get the
> settings for de.wikipedia.org?

Some further debugging showed that $wgConf->settings didn't
get set.  This code works with "php dumpSettings.php
zhwikivoyage":

| getAll ($argv [1]));

Testing it for example on
https://gerrit.wikimedia.org/r/109076/ shows changes in
wgAddGroups/sysop and wgRemoveGroups/sysop as expected.

Tim


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Non-complicated way to display configuration for a given wiki?

[Nathan Larson]

On Fri, Jan 24, 2014 at 9:35 AM, Tim Landscheidt wrote:

> Hi,
>
> to test changes to operations/mediawiki-config, I'd like to
> display the settings for a given wiki.
>
> So far I figured out:
>
> | 
> | $IP = 'wmf-config';
> | $cluster = 'pmtpa';
>
> | require ('/home/tim/public_html/w/includes/SiteConfiguration.php');
> | require ('wmf-config/wgConf.php');
>
> | var_dump ($wgConf->getAll ([...]));
>
> However, all my creativity regarding parameters to getAll()
> only returned an empty array.
>
> What would be the parameters needed for example to get the
> settings for de.wikipedia.org?


Are you saying you want to display the settings for your own wiki or
someone else's wiki (whose backend you can't access)? If it's your own
wiki, you can use
ViewFilesto let
people access a special page that will display a configuration file.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Dynamic search results as category pages

[Brad Jorsch (Anomie)]

On Fri, Jan 24, 2014 at 9:20 AM, Nik Everett  wrote:

>
> > On Jan 24, 2014, at 7:55 AM, Brian Wolff  wrote:
> > If we use this as category pages, im a little worried that people could
> get
> > confused and try to add [[category:Greek philosophers]] to a page, and
> > expect it to work. We would need good error handling in that situation
>
> Also, at least at first, you couldn't use one of these synthetic
> categories to filter search results so you couldn't use them to build other
> synthetic categories.
>

Don't forget the API. You'd probably need to bascally override
ApiQueryCategoryMembers to check cmtitle and either use parent::run() or a
custom implementation.

-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation


On Fri, Jan 24, 2014 at 9:20 AM, Nik Everett  wrote:

>
>
> Sent from my iPhone
>
> > On Jan 24, 2014, at 7:55 AM, Brian Wolff  wrote:
> >
> >> On Jan 24, 2014 1:54 AM, "Yuri Astrakhan" 
> wrote:
> >>
> >> Hi, I am thinking of implementing a
> >>
> >> #CATQUERY 
> >>
> >> magic keyword for the category pages.
> >>
> >> When this keyword is present, the category page would execute a query
> >> against the search backend instead of normal category behavior and show
> >> result as if those pages were actually marked with this category.
> >>
> >> For example, this would allow Greek Philosophers category page to be
> >> quickly redefined as
> >> a cross-section of greeks & philosophers categories:
> >>
> >> #CATQUERY incategory:Greek incategory:Philosopher
> >>
> >> Obviously the community will be able to define much more elaborate
> > queries,
> >> including the ordering (will be supported by the new search backend)
> >> ___
> >> Wikitech-l mailing list
> >> Wikitech-l@lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> > I like the idea in principle, but think the syntax could use
> bikeshedding ;)
> >
> > If we use this as category pages, im a little worried that people could
> get
> > confused and try to add [[category:Greek philosophers]] to a page, and
> > expect it to work. We would need good error handling in that situation
>
>
> Also, at least at first, you couldn't use one of these synthetic
> categories to filter search results so you couldn't use them to build other
> synthetic categories.
> >
> >> including the ordering (will be supported by the new search backend)
> >
> > Cool. I didnt realize search would support this. That's a pretty big deal
> > since people expect there categorirs alphabetized.
>
> So I looked into it and it would be easy to implement with Cirrus _but_
> I'm not yet sure about the memory implications. We have a ton of headroom
> on memory now so it might not matter but I need to test it before I can be
> as confident that it is ok as I was last night at 1am. It may have caveats
> like synthetic categories must be less than 1000 articles or not all
> results are included.
>
>
> >
> > Another cool project would be to expand intersection/Dyanamic P age List
> > (Wikimedia) to be able to use search as a different backend (however,
> that
> > extension would need quite a bit of refactoring to get there)
> >
> > -bawolff
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Dynamic search results as category pages

[Nik Everett]

Sent from my iPhone

> On Jan 24, 2014, at 7:55 AM, Brian Wolff  wrote:
> 
>> On Jan 24, 2014 1:54 AM, "Yuri Astrakhan"  wrote:
>> 
>> Hi, I am thinking of implementing a
>> 
>> #CATQUERY 
>> 
>> magic keyword for the category pages.
>> 
>> When this keyword is present, the category page would execute a query
>> against the search backend instead of normal category behavior and show
>> result as if those pages were actually marked with this category.
>> 
>> For example, this would allow Greek Philosophers category page to be
>> quickly redefined as
>> a cross-section of greeks & philosophers categories:
>> 
>> #CATQUERY incategory:Greek incategory:Philosopher
>> 
>> Obviously the community will be able to define much more elaborate
> queries,
>> including the ordering (will be supported by the new search backend)
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> 
> I like the idea in principle, but think the syntax could use bikeshedding ;)
> 
> If we use this as category pages, im a little worried that people could get
> confused and try to add [[category:Greek philosophers]] to a page, and
> expect it to work. We would need good error handling in that situation


Also, at least at first, you couldn't use one of these synthetic categories to 
filter search results so you couldn't use them to build other synthetic 
categories.
> 
>> including the ordering (will be supported by the new search backend)
> 
> Cool. I didnt realize search would support this. That's a pretty big deal
> since people expect there categorirs alphabetized.

So I looked into it and it would be easy to implement with Cirrus _but_ I'm not 
yet sure about the memory implications. We have a ton of headroom on memory now 
so it might not matter but I need to test it before I can be as confident that 
it is ok as I was last night at 1am. It may have caveats like synthetic 
categories must be less than 1000 articles or not all results are included. 


> 
> Another cool project would be to expand intersection/Dyanamic P age List
> (Wikimedia) to be able to use search as a different backend (however, that
> extension would need quite a bit of refactoring to get there)
> 
> -bawolff
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Dynamic search results as category pages

[Brian Wolff]

On Jan 24, 2014 1:54 AM, "Yuri Astrakhan"  wrote:
>
> Hi, I am thinking of implementing a
>
> #CATQUERY 
>
> magic keyword for the category pages.
>
> When this keyword is present, the category page would execute a query
> against the search backend instead of normal category behavior and show
> result as if those pages were actually marked with this category.
>
> For example, this would allow Greek Philosophers category page to be
> quickly redefined as
> a cross-section of greeks & philosophers categories:
>
> #CATQUERY incategory:Greek incategory:Philosopher
>
> Obviously the community will be able to define much more elaborate
queries,
> including the ordering (will be supported by the new search backend)
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I like the idea in principle, but think the syntax could use bikeshedding ;)

If we use this as category pages, im a little worried that people could get
confused and try to add [[category:Greek philosophers]] to a page, and
expect it to work. We would need good error handling in that situation

> including the ordering (will be supported by the new search backend)

Cool. I didnt realize search would support this. That's a pretty big deal
since people expect there categorirs alphabetized.

Another cool project would be to expand intersection/Dyanamic Page List
(Wikimedia) to be able to use search as a different backend (however, that
extension would need quite a bit of refactoring to get there)

-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Non-complicated way to display configuration for a given wiki?

[Tim Landscheidt]

Hi,

to test changes to operations/mediawiki-config, I'd like to
display the settings for a given wiki.

So far I figured out:

| getAll ([...]));

However, all my creativity regarding parameters to getAll()
only returned an empty array.

What would be the parameters needed for example to get the
settings for de.wikipedia.org?

TIA,
Tim


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Dynamic search results as category pages

[Yuri Astrakhan]

Hi, I am thinking of implementing a

#CATQUERY 

magic keyword for the category pages.

When this keyword is present, the category page would execute a query
against the search backend instead of normal category behavior and show
result as if those pages were actually marked with this category.

For example, this would allow Greek Philosophers category page to be
quickly redefined as
a cross-section of greeks & philosophers categories:

#CATQUERY incategory:Greek incategory:Philosopher

Obviously the community will be able to define much more elaborate queries,
including the ordering (will be supported by the new search backend)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l