Is there any chance for progress to be made on this? I recently ran
into this problem again at a featured article candidate I was
reviewing. It is has a very worthy 'National Historic Landmarks' set
of templates at the bottom, but unfortunately this leads to massive
template linkage bloat. Of the over 100 articles that link to this
article, I estimate that only three links are from within the text of
other articles - the rest are from the templates.
If I had been able to see at a glance that this article was linked
from two other articles, I would have been able to make a suggestion
to link back to those articles, and maybe link from other articles. As
it was, I was unable to do this and this caused some problems (which
it is best not to go into here).
So is there anyway to encourage or help with whatever needs to be done here?
Carcharoth
On Mon, Feb 7, 2011 at 4:10 AM, David Goodman <dggenwp(a)gmail.com> wrote:
> agreed. The footer templates are the biggest source of linkage bloat.
> the templates are useful, and we need some way of keeping track of
> what should be in them when we add or delete articles, but they make
> working with what links here for any practical purpose extremely
> difficult. They'd be much more helpful if they were separated.
>
> On Sun, Feb 6, 2011 at 9:52 PM, Carcharoth <carcharothwp(a)googlemail.com> wrote:
>> On Mon, Feb 7, 2011 at 1:34 AM, Tim Starling <tstarling(a)wikimedia.org> wrote:
>>> On 07/02/11 10:56, Carcharoth wrote:
>>>> On Sun, Feb 6, 2011 at 10:19 PM, Magnus Manske
>>>> <magnusmanske(a)googlemail.com> wrote:
>>>>
>>>>> Many of these links are due to templates, which I can do little about.
>>>>
>>>> Can *anyone*, even in principle, do something about that? It really
>>>> bugs me that the "what links here" function doesn't distinguish
>>>> between links arising from templates (often not directly relevant) and
>>>> links directly from the article wiki-text. If the answer is something
>>>> to do with parsers, please do explain!
>>>
>>> Yes, it's possible. It was necessary to register links from templates
>>> in the pagelinks table so that when a page is deleted or created, the
>>> HTML caches can be updated so that the link colour will change. With a
>>> schema change and some parser work, it would be possible to flag such
>>> links so that they are optional in "what links here".
>>
>> That would be wonderful. It might even get me to create a bugzilla
>> account to vote for a bug if there is one open on this...(of course,
>> one problem is still that some templates are relevant to article
>> content and some are not - the ones that generate distracting links
>> are the navigational ones that tend to be at the bottom of pages, the
>> footer templates - and I'm not sure if infobox links would count as
>> template links or not - they are generated from parsing of a template
>> parameter, but don't appear in the template itself, unlike the footer
>> navboxes).
>>
>> [In case anyone is confused, an example is the massive footer
>> templates that can lead to Nobel prize winners decades apart linking
>> to each other, or diverse topics within a broad area linking to each
>> other, though only through templates and not in the text. Oh, and some
>> links appear in both footer templates, infoboxes, and the article
>> 'text'. Not sure how that is handled.]
>>
>> Carcharoth
>>
>> _______________________________________________
>> WikiEN-l mailing list
>> WikiEN-l(a)lists.wikimedia.org
>> To unsubscribe from this mailing list, visit:
>> https://lists.wikimedia.org/mailman/listinfo/wikien-l
>>
> --
> David Goodman
>
> DGG at the enWP
> http://en.wikipedia.org/wiki/User:DGG
> http://en.wikipedia.org/wiki/User_talk:DGG
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l(a)lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> https://lists.wikimedia.org/mailman/listinfo/wikien-l
>
Hi everyone,
I wanted to point English Wikipedians to a cool update for the experimental
Feedback Dashboard, and invite you all to try it out and come to our IRC
office hours this weekend about it.
The full details on the Village Pump:
https://en.wikipedia.org/wiki/Wikipedia:VPT#New_functionality_for_our_first…
As far as I am aware, this is the first time that there is a single place
on-wiki where you can see new editor feedback appear in real time, filter
it based on sentiment, and respond without leaving the page. If you find it
interesting, please join our taskforce on this, WP:RESPONSE.
Thanks,
--
Steven Walling
Community Organizer at Wikimedia Foundation
wikimediafoundation.org
Without knowledge, myths are born. With myths, fear is born. With fear,
intolerance is born. With intolerance, ignorance is born. With ignorance,
nothing is born.
MR
On Thu, Oct 13, 2011 at 9:56 PM, Gwern Branwen <gwern0(a)gmail.com> wrote:
> Yes, it was pretty abrupt. See Jason Scott on this issue and how it
> wasn't even announced but buried in some obscure Yahoo documentation
> entry.
Google to its credit didn't bury the death notice in help, but they
didn't exactly highlight it:
http://googleblog.blogspot.com/2011/11/more-spring-cleaning-out-of-season.h…
> Knol—We launched Knol in 2007 to help improve web content by enabling experts to collaborate on in-depth articles. In order to continue this work, we’ve been working with Solvitor and Crowd Favorite to create Annotum, an open-source scholarly authoring and publishing platform based on WordPress. Knol will work as usual until April 30, 2012, and you can download your knols to a file and/or migrate them to WordPress.com. From May 1 through October 1, 2012, knols will no longer be viewable, but can be downloaded and exported. After that time, Knol content will no longer be accessible.
That's surprisingly harsh - when I looked through past shut-downs (
http://www.gwern.net/Wikipedia%20and%20Knol#knol-death-watch ), Google
seemed to usually preserve *public* material as static files. But in
this case, they seem to be saying the Knol content will be completely
purged off their servers.
(Which is a good lesson that Jason Scott would also appreciate,
anyway, about trusting the cloud with your content. Not that trusting
your content to Wikipedia is much better, from the long-term point of
view.)
--
gwern
http://www.gwern.net
Hi everyone,
I just wanted to invite anyone interested to join an informal taskforce for
responding to comments/questions left by new editors on the experimental
Feedback Dashboard (Special:FeedbackDashboard).
You can sign up and see some documentation at:
https://en.wikipedia.org/wiki/Wikipedia:Feedback_Dashboard
This feature is still very much a work in progress.
In the meantime, I really feel excited about the potential to respond to
folks needing help. I've done a few hours of patrolling and I know others
have also jumped in and started to leave talk pages messages for these
newbies already. I find it fun to try and find the new editors who are
working hard to "get it", but need a little helping hand.
Actively using the dashboard will also help uncover any bugs that need
addressing. Using it also helps inform the tech team at the WMF about new
functionality it needs to really work well. So don't be shy about using the
talk page, please.
Let me or Maryana know if you have any questions. (I've signed up for the
taskforce with my non-staff account, so I'll be patrolling as well.)
--
Steven Walling
Community Organizer at Wikimedia Foundation
wikimediafoundation.org
P.S. I've left some suggestions for a system of response etc. on the wiki
page. These are just suggestions, not marching orders or an edict from the
Foundation. ;-)
Hi folks,
we'd appreciate additional testers for the new multi-file selection
feature of UploadWizard. Please see link below for more details.
This affects every Wikipedian who uploads freely licensed media files,
so I thought I'd post it here as well :)
Cheers,
Erik
---------- Forwarded message ----------
From: Erik Moeller <erik(a)wikimedia.org>
Date: Fri, Nov 4, 2011 at 5:15 PM
Subject: Please test multi-file selection
To: commons-l(a)lists.wikimedia.org
Multi-file selection, perhaps the single most requested feature for
UploadWizard, is now ready for testing on a staging wiki. Please see
Neil's announcement here:
http://commons.wikimedia.org/wiki/Commons:Village_pump#Multi-file_selection…
I'm really excited about this, as it's the first step to making large
uploads a lot more manageable without the use of third party tools
like Commonist.
Other improvements in the next release that you can test now will
include a better licensing workflow, including support for custom
wikitext licenses, and automatic extraction of file-embedded
geographic coordinates and display of those coordinates using a
template.
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate