Put __HIDDENCAT__ on the category page to hide that category from the list at the bottom of the article pages. This feature is intended to reduce the clutter from maintenance categories like [[Category:Articles with unsourced statements since December 2007]].
A feature to show the hidden categories for a page has been proposed, and is entirely possible in the backend, but the user inteface details have not been sorted out yet.
Red links now display text from [[MediaWiki:Red-link-title]] in their title attribute. By default, this is "(not yet written)" after the destination name. This feature is intended to inform casual readers of the nature of a red link.
Red links now point to action=editredlink instead of action=edit. The new action is more lenient in displaying edit permission errors, to avoid offending readers who are blocked and clicked a red link with no intention of editing.
Specifically, it redirects to the view page if the user doesn't have edit permissions, thus requiring the user to explicitly click the "edit" tab in order to see a block message.
The new parser is now live on all Wikimedia wikis.
The format of various MediaWiki namespace messages has been changed, to allow templates and parser functions in a much more intuitive way, similar to ordinary articles. Some local messages have hacks to work around bugs in the old parser, these hacks will need to be removed.
-- Tim Starling
"Tim Starling" tstarling@wikimedia.org wrote in message news:fplp2t$3i3$1@ger.gmane.org...
Put __HIDDENCAT__ on the category page to hide that category from the list at the bottom of the article pages. This feature is intended to reduce the clutter from maintenance categories like [[Category:Articles with unsourced statements since December 2007]].
Wouldn't it be better to use something like __ADMINCAT__ (either as well, or instead of, the above)? This would indicate that the category is used for administering the wiki, rather than for navigating the content. For pages with admin categories, a second category box 'Administrative categories' would be added, which can be expanded/collapsed (collapsed by default) so these categories can still be found and used by editors.
- Mark Clements (HappyDog)
On 22/02/2008, Mark Clements gmane@kennel17.co.uk wrote:
"Tim Starling" tstarling@wikimedia.org wrote in message news:fplp2t$3i3$1@ger.gmane.org...
Put __HIDDENCAT__ on the category page to hide that category from the list at the bottom of the article pages. This feature is intended to reduce the clutter from maintenance categories like [[Category:Articles with unsourced statements since December 2007]].
Wouldn't it be better to use something like __ADMINCAT__ (either as well, or instead of, the above)? This would indicate that the category is used for administering the wiki, rather than for navigating the content. For pages with admin categories, a second category box 'Administrative categories' would be added, which can be expanded/collapsed (collapsed by default) so these categories can still be found and used by editors.
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.
Something semantic would seem better, yes.
I disagree. The feature isn't specifically about administrative categories, it's about hidden categories, so HIDDENCAT makes sense. You could have an alias, I suppose.
Are there other meanings for which you'd want to hide the category?
Who knows? People use Mediawiki for all kinds of things.
And should stub categories be hidden by default?
Does the phrase "stub category" have any meaning to the software? Aren't they just like any other category? In which case, whether or not they're hidden is a matter for individual wikis.
David Gerard wrote:
On 22/02/2008, Mark Clements gmane@kennel17.co.uk wrote:
"Tim Starling" tstarling@wikimedia.org wrote in message news:fplp2t$3i3$1@ger.gmane.org...
Put __HIDDENCAT__ on the category page to hide that category from the list at the bottom of the article pages. This feature is intended to reduce the clutter from maintenance categories like [[Category:Articles with unsourced statements since December 2007]].
Wouldn't it be better to use something like __ADMINCAT__ (either as well, or instead of, the above)? This would indicate that the category is used for administering the wiki, rather than for navigating the content. For pages with admin categories, a second category box 'Administrative categories' would be added, which can be expanded/collapsed (collapsed by default) so these categories can still be found and used by editors.
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?
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
"Tim Starling" tstarling@wikimedia.org wrote in message news:fpmqa3$hob$1@ger.gmane.org...
David Gerard wrote:
On 22/02/2008, Mark Clements
gmane@kennel17.co.uk wrote:
"Tim Starling" tstarling@wikimedia.org
wrote in
message news:fplp2t$3i3$1@ger.gmane.org...
Put __HIDDENCAT__ on the category page to hide that category from the
list
at the bottom of the article pages. This feature is intended to
reduce the
clutter from maintenance categories like [[Category:Articles with unsourced statements since December 2007]].
Wouldn't it be better to use something like __ADMINCAT__ (either as
well, or
instead of, the above)? This would indicate that the category is used
for
administering the wiki, rather than for navigating the content. For
pages
with admin categories, a second category box 'Administrative
categories'
would be added, which can be expanded/collapsed (collapsed by default)
so
these categories can still be found and used by editors.
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?
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.
That wasn't really the point of my original suggestion. The point is that it would be more useful to separate out the administrative categories (aimed at editors) from the standard categories (aimed at readers). Both should be displayed on the page, but separated from each other (with, as I say, the admin categories initially hidden if JS is enabled).
- Mark Clements (HappyDog)
Mark Clements wrote:
That wasn't really the point of my original suggestion. The point is that it would be more useful to separate out the administrative categories (aimed at editors) from the standard categories (aimed at readers). Both should be displayed on the page, but separated from each other (with, as I say, the admin categories initially hidden if JS is enabled).
Right, but when that feature becomes available, you can change the template.
-- Tim Starling
"Tim Starling" tstarling@wikimedia.org wrote in message news:fpnvh2$dh7$1@ger.gmane.org...
Mark Clements wrote:
That wasn't really the point of my original suggestion. The point is
that
it would be more useful to separate out the administrative categories
(aimed
at editors) from the standard categories (aimed at readers). Both
should be
displayed on the page, but separated from each other (with, as I say,
the
admin categories initially hidden if JS is enabled).
Right, but when that feature becomes available, you can change the
template.
Are you implying by that that something along the lines of my suggestion is already in the pipeline? Sounds promising....
- Mark Clements (HappyDog)
On Sat, Feb 23, 2008 at 02:38:45AM +1100, Tim Starling 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?
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.
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
Put __HIDDENCAT__ on the category page to hide that category from the list at the bottom of the article pages. This feature is intended to reduce the clutter from maintenance categories like [[Category:Articles with unsourced statements since December 2007]].
I was just looking at using this feature on commons, where license categories clutter the category lists of image pages considerably (and provide redundant information, as we already have template for the licenses).
I tagged a few cats with __HIDDENCAT__, but unfortunately, while useful for the image pages, it screws up category tree navigation. Numerous licenses have finer grained subcategories (such as i.e. PD-old).
How about disabling the category hiding for the category namespace?
How about disabling the category hiding for the category namespace?
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 Fri, Feb 22, 2008 at 3:36 PM, Daniel Schwen lists@schwen.de wrote:
How about disabling the category hiding for the category namespace?
Or maybe for all non-content namespaces.
On Sat, Feb 23, 2008 at 12:40 AM, Simetrical Simetrical+wikilist@gmail.com wrote:
On Fri, Feb 22, 2008 at 3:36 PM, Daniel Schwen lists@schwen.de wrote:
How about disabling the category hiding for the category namespace?
Or maybe for all non-content namespaces.
I would second that.
2008/2/22, Tim Starling tstarling@wikimedia.org:
Put __HIDDENCAT__ on the category page to hide that category from the list at the bottom of the article pages. This feature is intended to reduce the clutter from maintenance categories like [[Category:Articles with unsourced statements since December 2007]].
Thank you so much for this magic word. This is a very nice surprise.
This works very well for the Cookbook in Dutch Wikibooks. For the ingredients we would like to present the recipes in which this ingredient is used on the page about this ingredient. We do this by categorizing every recipe with a special category per ingredient. This could result in endless lists of categories under the recipe page (and that looks ugly). The content of these categories are used with the extension DynamicPageList to generate a list of recipes in which this ingredient is used on the page about this ingredient. This magic word solves the problem about the ugliness of using a lot of categories on the page of the recipee.
The only thing which would even be better, is when DynamicPageList could generate a list in alphabetic order.....
So thanks again a, for me at least, very useful tool.
Kind regards, Londenp
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@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.....
Dynamicpagelist is ordering according to date when a page is added to a category.
Ordering by alphabet is not a feature (yet), alas.
Kind regards. Londenp
2008/2/22, Siebrand Mazeland s.mazeland@xs4all.nl:
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@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.....
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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:
Dynamicpagelist is ordering according to date when a page is added to a category.
Ordering by alphabet is not a feature (yet), alas.
Kind regards. Londenp
2008/2/22, Siebrand Mazeland s.mazeland@xs4all.nl:
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@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.....
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
2008/2/23, DanTMan dan_the_man@telus.net:
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.
Yes sorry, I didn't mean order by alphabet, but sorting by alphabet.
Read over http://semeb.com/dpldemo/DPL:Manual when you need info on DPL
parameters.
This is a further developed version of the first Dynamicpagelist
However, it looks as if you are talking about the extremely ancient
version of DPL which no-one uses.
Well, it is being used on Wikimedia-projects.
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
Are you really sure this is active on Wikimedia-projects, because in my opinion this version is active on Wikimedia projects: *http://www.mediawiki.org/wiki/Extension:DynamicPageList/old
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
Thanks I will try it on my testwiki at home and if appropriate I will make an entrance on bugzilla.
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)
Thanks for the information. Londenp
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:
2008/2/23, DanTMan dan_the_man@telus.net:
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.
Yes sorry, I didn't mean order by alphabet, but sorting by alphabet.
Read over http://semeb.com/dpldemo/DPL:Manual when you need info on DPL
parameters.
This is a further developed version of the first Dynamicpagelist
However, it looks as if you are talking about the extremely ancient
version of DPL which no-one uses.
Well, it is being used on Wikimedia-projects.
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
Are you really sure this is active on Wikimedia-projects, because in my opinion this version is active on Wikimedia projects: *http://www.mediawiki.org/wiki/Extension:DynamicPageList/old
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
Thanks I will try it on my testwiki at home and if appropriate I will make an entrance on bugzilla.
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)
Thanks for the information. Londenp _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2008/2/24, DanTMan dan_the_man@telus.net:
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.
Indeed.
But we have the old DPL installed on Wikibooks-NL as well and there are probably several other Wikimedia wikis as well. My wish to install the new DPL on Wikibooks, was turned down, alas, as this is not in the Wikimedia repository and the old one is (if I remember this correctly). I still hope I can some day make a patch (which is difficult if you have zero experience with PHP) to have at least a sorting in alphabetical order possible for the old DPL. More simple would be to install the new DPL.
This is still something I would like to find out if this is possible: is there a possibility to have an overview of installed extensions on all different Wikimedia projects? For instance: how can I found out on which projects DPL is installed and on which projects Extension:Quiz, without have the look at all Special:Version pages.
Londenp
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)
On Sun, Feb 24, 2008 at 7:37 AM, Peter van Londen londenp@gmail.com wrote:
My wish to install the new DPL on Wikibooks, was turned down, alas, as this is not in the Wikimedia repository and the old one is (if I remember this correctly).
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 Fri, Feb 22, 2008 at 05:11:40PM +1100, Tim Starling wrote:
Put __HIDDENCAT__ on the category page to hide that category from the list at the bottom of the article pages. This feature is intended to reduce the clutter from maintenance categories like [[Category:Articles with unsourced statements since December 2007]].
A feature to show the hidden categories for a page has been proposed, and is entirely possible in the backend, but the user inteface details have not been sorted out yet.
Hide them with CSS and put in a quick mini-AJAXy link/button to unhide them (as with "open links in a new window")?
Red links now display text from [[MediaWiki:Red-link-title]] in their title attribute. By default, this is "(not yet written)" after the destination name. This feature is intended to inform casual readers of the nature of a red link.
Oh, cool.
Red links now point to action=editredlink instead of action=edit. The new action is more lenient in displaying edit permission errors, to avoid offending readers who are blocked and clicked a red link with no intention of editing.
Specifically, it redirects to the view page if the user doesn't have edit permissions, thus requiring the user to explicitly click the "edit" tab in order to see a block message.
That sounds like a win.
The new parser is now live on all Wikimedia wikis.
We rewrote the parser?? :-)
Was this a version release or a slipstream? I don't see that you mentioned.
Cheers, -- jra
On 2/23/08, Jay R. Ashworth jra@baylink.com wrote:
We rewrote the parser?? :-)
Was this a version release or a slipstream? I don't see that you mentioned.
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).
On Sat, Feb 23, 2008 at 10:26:04AM +1100, Andrew Garrett wrote:
On 2/23/08, Jay R. Ashworth jra@baylink.com wrote:
We rewrote the parser?? :-)
Was this a version release or a slipstream? I don't see that you mentioned.
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).
Oh; ok. Yeah; I'd seen the edges of that traffic.
Cheers, -- jra
On Fri, Feb 22, 2008 at 5:25 PM, Jay R. Ashworth jra@baylink.com wrote:
Hide them with CSS and put in a quick mini-AJAXy link/button to unhide them (as with "open links in a new window")?
The answer to any feature suggestion beginning "Hide them with CSS" is "no".
Simetrical wrote:
On Fri, Feb 22, 2008 at 5:25 PM, Jay R. Ashworth wrote:
Hide them with CSS and put in a quick mini-AJAXy link/button to unhide them (as with "open links in a new window")?
The answer to any feature suggestion beginning "Hide them with CSS" is "no".
Why? It makes sense to have them with class="hiddencat" and using javascript (not AJAX) to toggle between 'user' and 'editor' view.
Also, i wonder how do you want to show and hide tocs ;)
On Mon, Feb 25, 2008 at 5:43 AM, Platonides Platonides@gmail.com wrote:
Why? It makes sense to have them with class="hiddencat" and using javascript (not AJAX) to toggle between 'user' and 'editor' view.
Also, i wonder how do you want to show and hide tocs ;)
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.
On Mon, Feb 25, 2008 at 12:32 PM, Simetrical Simetrical+wikilist@gmail.com wrote:
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.
Well, it seems that Tim disagrees with this.
Simetrical wrote:
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.
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.
On Mon, Feb 25, 2008 at 4:55 PM, Platonides Platonides@gmail.com 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.
Well, as I said: just showing it may in some cases, possibly including this one, be a good fallback. I was more objecting to the lack of consideration than to the proposed functionality itself.
TS> Red links now display text from [[MediaWiki:Red-link-title]] in their TS> title attribute. By default, this is "(not yet written)" after the TS> destination name. This feature is intended to inform casual readers of the TS> nature of a red link.
All I see is <a href="/w/index.php?title=Reddddddlink&action=editredlink" class="new" title="Reddddddlink">reddddddlink</a>
$ GET 'http://en.wikipedia.org/w/index.php?title=MediaWiki:Red-link-title&actio...' $1
I don't see where the "(not yet written)" enters the picture.
jidanni@jidanni.org wrote:
TS> Red links now display text from [[MediaWiki:Red-link-title]] in their TS> title attribute. By default, this is "(not yet written)" after the TS> destination name. This feature is intended to inform casual readers of the TS> nature of a red link.
All I see is <a href="/w/index.php?title=Reddddddlink&action=editredlink" class="new" title="Reddddddlink">reddddddlink</a>
$ GET 'http://en.wikipedia.org/w/index.php?title=MediaWiki:Red-link-title&actio...' $1
I don't see where the "(not yet written)" enters the picture.
http://en.wikipedia.org/w/index.php?title=MediaWiki:Red-link-title&actio...
Should be "$1 (not yet written)"
-- Tim Starling
TS> Specifically, it redirects to the view page if the user doesn't have edit TS> permissions, thus requiring the user to explicitly click the "edit" tab in TS> order to see a block message.
Wish categories with members but no text would not trigger the gaping edit box for users to doodle in.
Yes tried permissions stuff last time but then they could not even see the members.
You see, on http://radioscanningtw.jidanni.org/ a category represents a frequency, with no text desired.
Yes could hack source to turn red links blue, but maintenance nightmare then.
So have http://radioscanningtw.jidanni.org/index.php?title=Template:C but still no cure for aforementioned booby trapped red category links at the bottom of pages.
wikitech-l@lists.wikimedia.org