On 22/02/2008, Mark Clements <gmane(a)kennel17.co.uk> wrote: Something semantic would seem better, yes. Are there other meanings for which you'd want to hide the category? And should stub categories be hidden by default? - d.

David Gerard wrote: You can always use a template, if you want semantic annotation. A template containing __HIDDENCAT__ would make any category that included it a hidden category. -- Tim Starling

Mark Clements wrote: Right, but when that feature becomes available, you can change the template. -- Tim Starling

On Sat, Feb 23, 2008 at 02:38:45AM +1100, Tim Starling wrote: FWIW, I concur that the *mechanism* should probably be results-based, as long as you can *wrap* it in semantic sugar, which here, you can. This implies that the online documentation that tells people how to make use of it should make this point, and possibly explicitly discourage people from using the underlying facility without (creating) a semantic wrapper. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin)

Agreed, subcatagories should be shown on the category page whether they are administrative or not. At the very least, a hidden subcat of a hidden cat should show up. There is a case for hidden subcats of nonhidden cats still being hidden (for the benefit of [[Category:Categories requiring cleanup]] or whatever).

On Sat, Feb 23, 2008 at 12:40 AM, Simetrical <Simetrical+wikilist(a)gmail.com> wrote: I would second that.

http://meta.wikimedia.org/wiki/DynamicPageList explains that specifying a sort order is possible, and it does appear to do something if you use "order=descending" or "order=ascending". It just does not give the expected result (a properly sorted list). Looks like a bug that needs squashing... Cheers! Siebrand -----Oorspronkelijk bericht----- Van: wikitech-l-bounces(a)lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Namens Peter van Londen Verzonden: vrijdag 22 februari 2008 22:35 Aan: Wikimedia developers Onderwerp: Re: [Wikitech-l] New features [..] The only thing which would even be better, is when DynamicPageList could generate a list in alphabetic order.....

order= is a parameter to control the direction of the order, not what the list is ordered by, To control what the list is ordered by you use ordermethod for what you want, the best thing to use would be ordermethod=titlewithoutnamespace. Read over http://semeb.com/dpldemo/DPL:Manual when you need info on DPL parameters. However, it looks as if you are talking about the extremely ancient version of DPL which no-one uses. Yes, nice sorting and complex methods is part of DPL, however you are using the wrong one. For the newest version of DPL in use see: http://www.mediawiki.org/wiki/Extension:DynamicPageList However, there is another extension which may actually work much better for you. Your case looks like Semantic data would fit it much better. I would suggest using Semantic MediaWiki. http://www.mediawiki.org/wiki/Extension:Semantic_MediaWiki Using that rather than a category for every recipe has a number of advantages. * Rather than a category and a recipe page, you have one recipe page which is used both like a recipe and a category. * Using the semantic attributes you can actually browse the semantic data on the wiki (ie: Jump from a recipe to a ingredient and find out what other recipes it's used in) * The Ask queries you use can contain info in a much clearer way than DPL does. * You can generate lists on things like, what ingredients are in a recipe, what recipes use an ingredient, etc... Easily with just a special page. * SMW does not force a page into a no-cache mode, and uses it's own table rather than a collection of existing ones. As a result for these kind of uses it has a smaller footprint on your server than using DPL. ~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com) Peter van Londen wrote:

The old DPL (For some reason called Intersection) is only installed on Meta and Wikinews. The actual Wikimedia wiki such as Wikipedia don't even have it installed. The old DPL doesn't have an option for alphabetical sorting, and it never will because the new DPL was created for the purpose of giving those extra features. The old DPL is only used on those Wikimedia projects because they have need of some DPL functions, but have no real need for anything special. However, the newer DPL is installed on Wikia. DPL is common use on Wikia, not Wikimedia where it isn't under any common use aside from a few wiki which have restricted use of it. Wikimedia doesn't even make use of the DPLforums. ~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com) Peter van Londen wrote:

On Sun, Feb 24, 2008 at 7:37 AM, Peter van Londen <londenp(a)gmail.com> wrote: Well, being in the Wikimedia repo is a prerequisite, but the actual reason is more that it hasn't been reviewed sufficiently for performance and things like that, and from what I've heard probably wasn't written to begin with with such concerns being paramount. If there were no other issues it could just be uploaded to Subversion by any committer.

On 2/23/08, Jay R. Ashworth <jra(a)baylink.com> wrote: Tim did, about a month ago. Where have you been? ;-) He didn't rewrite the whole parser, though. Just the preprocessor (which, I'm told, is quite a significant part of the parser). -- Andrew Garrett

On Fri, Feb 22, 2008 at 5:25 PM, Jay R. Ashworth <jra(a)baylink.com> wrote: The answer to any feature suggestion beginning "Hide them with CSS" is "no".

On Mon, Feb 25, 2008 at 5:43 AM, Platonides <Platonides(a)gmail.com> wrote: TOCs are shown by default. If users have JavaScript, they will gain additional functionality, and be able to hide them. If they don't, the default display will be the same, they'll just be unable to change it dynamically -- since it's not technically possible to execute changes to the page without JavaScript, or of course reloading the page. The suggestion here was to have the content included like any other content, but hidden using CSS. The implicit assumption here is that every user agent supports CSS. This is wrong; search engine spiders, for instance, do not. Not all mobile devices do, although that's changing. A small minority of users may also for whatever reason choose to use browsers such as lynx, that also do not support CSS. Now, when a feature *needs* CSS or JS, and cannot be executed otherwise, we should use CSS and JS, with graceful fallback if the user agent doesn't have it. Graceful fallback doesn't include just displaying stuff that you meant to be hidden, without thinking about it. In some cases, it may actually include displaying stuff that's hidden for other users, but only when, *on consideration*, that's the best fallback possible. Since neither Jay nor you actually mentioned fallbacks, I assume you weren't thinking of them when you suggested to use CSS to hide things, which is where my response came from. I don't necessarily oppose display: none entirely; it has some perfectly legitimate uses. In this case, I'm not sure we need an interface for this on the page at all. Instead, the page can be seen as a member of a category by looking at the category page. This is very reasonable for maintenance categories, where you usually don't need to know that a given article is tagged for cleanup if you're just reading it: the purpose of the category is to allow people to systematically go through all articles in the category, via the category page. Adding a button to show the hidden categories adds interface clutter and partially reintroduces the confusion for ordinary readers that the goal of hidden categories is to remove. In some cases, furthermore, the reason for hiding categories may be that there are dozens of them, which repeat information already contained in displayed categories, and which are therefore useless for everyone -- see the proposal made a couple of days ago here to use this to increase the number of "manual category intersections" like "American artists", and have the visible categories be only atomic categories like "United States citizens" and "Artists". In this use case, any option to display all the categories on the page would just display a complete mess, and would be useless for anyone. So I would say that __HIDDENCAT__ should just be hidden for now, period, no interface to display it. As time progresses and people start using the feature extensively, if people report that some additional level of display would be useful, we can discuss that then.

Simetrical wrote: I thought to have that hidden, something like a second "Category bar", Let's call it "Administrative categories". If the browser doesn't support CSS it will be shown, granted. But what's the problem on having google seeing them, or a user viewing with a soimple browser. We hide it when it can be shown later with javascript, but if it won't be able to show it, having them showed is acceptable.