I'm not really sure if Cargo is the right option, but it's the simplest
alternative I know of to SMW.
Perhaps categories would suffice, if the important stats can be
expressed just as category counts. It sounds like it could get annoying
though.
I do feel a bit like we'd be missing a win if, for the query-able data
in a site about MediaWikis, we were forced to build a custom extension
for doing the querying. It's the sort of thing that lots of wikis want
to do! But maybe it's the best way to go.
On 27/12/23 17:16, Jesús Martínez wrote:
> Hi,
>
> Sam proposes switching to Cargo. However, from what I've heard (and I
> haven't used Cargo myself), Cargo is another beast and comes with its
> own problems as well. Someone with more experience with Cargo should
> probably assess whether it would be a good idea or not to use Cargo
> here. Maybe there's a way to do roughly the same queries by using
> categories instead, and the help of one of the available
> DynamicPageList extensions.
>
> Best regards,
>
> --
> Jesús Martínez
> Ciencia Al Poder
>
> El mié, 27 dic 2023 a las 2:29, Sam Wilson (<sam(a)samwilson.id.au>) escribió:
>> My understanding is that the basic structure of Wikiapiary is firstly a
>> system of templates etc that stores data from the sites' pages into SMW
>> and then reads it out for various reports; and secondly the scripts that
>> populate the wikitext pages with data fetched from the sites (and
>> extensions etc). The really valuable bits to me are the fact of having a
>> categorized/tagged index to MediaWiki sites, and the extension
>> popularity info. The first part of that is most valuable as a
>> human-curated thing, so I think that'd make sense to get back online
>> even if it wasn't bot-updated. The extension and other site info is
>> silly to update by hand, but there isn't an absolute reason that the
>> bots doing the updating need to be part of the WikiApiary
>> infrastructure, so perhaps if WikiApiary was online, a new system of
>> fetching site info could be built.
>>
>> Then, of course, is the separate issue of *how* to store the info on the
>> wiki. It's SMW at the moment, but it sounds like that hits some resource
>> issues given the number of queries being run and the amount of data.
>> Would Cargo be better? I feel like switching to that would be not an
>> insurmountable thing to do (compared to say moving to Wikibase to store
>> the data, which would be a bigger restructure). The individual sites'
>> pages mightn't even need to be changed (if all the storage/querying
>> logic is in templates and modules).
>>
>> I vote for bringing it online again now, even if it's without SMW or the
>> bots, and updating it to the latest MediaWiki. If any of that's possible
>> of course.
>>
>> Thank you for working on it! I'm not sure how much time I've got to
>> help, but I'd love to try.
>>
>> —Sam
>>
>>
>> On 27/12/23 08:47, Mark A. Hershberger wrote:
>>> Triple Camera <TripleCamera(a)outlook.com> writes:
>>>
>>>> The database has been locked for half a year, Bots and editors are
>>>> waiting, and they are losing patience. I believe the most urgent thing
>>>> to do is to make WikiApiary back online as soon as possible.
>>> If we brought WikiApiary back online right now without the bots, would
>>> that be acceptable?
>>>
>>> I'm trying to understand what you need from the site and how you've
used
>>> it, so any information you have would be useful.
>>>
>>> If you or other users of the site can let us know how you would like to
>>> use it, that well help us make sure we are able bring it back online in
>>> as useful a way as possible.
>>>
>>> Mark.
>>>
>> _______________________________________________
>> Wikiapiary mailing list -- wikiapiary(a)lists.wikimedia.org
>> To unsubscribe send an email to wikiapiary-leave(a)lists.wikimedia.org
> _______________________________________________
> Wikiapiary mailing list -- wikiapiary(a)lists.wikimedia.org
> To unsubscribe send an email to wikiapiary-leave(a)lists.wikimedia.org