Re: [Wikitech-l] What is "revision slot" and why is it necessary to specify it now?

ode running on the site has access to the version from JS variables. -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Today: TechCom office hour about RFC process

://www.mediawiki.org/wiki/Requests_for_comment/Process -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Ops] Backport and Config changes window (name change)

"Beam" would be quite expressive, IMO: > > "Beam up the patches, Scotty!" > Excuse my nerding... ;-) > > Demian (aka. Aron) > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > h

[Wikitech-l] TechCom Radar 2020-06-24

subscribe to our newsletter here <https://www.mediawiki.org/wiki/Newsletter:TechCom_Radar> -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimed

Re: [Wikitech-l] Hard deprecation of the Revision class

kimedia.org/r/c/mediawiki/core/+/608845 > 2. https://phabricator.wikimedia.org/T246284 > 3. https://www.mediawiki.org/wiki/Stable_interface_policy#Deprecation > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > ht

Re: [Wikitech-l] Service wiring conventions in extensions

static variable, but if you want to prepare for the bright an shiny future, you can also make TranslateServices a service in MediaWikiServices :) -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mail

[Wikitech-l] Making breaking changes without deprecation?

ce_policy [2] https://www.mediawiki.org/wiki/Topic:Vrwr9aloe6y1bi2v [3] https://phabricator.wikimedia.org/T193613 [4] https://phabricator.wikimedia.org/T255803 [5] https://codesearch.wmcloud.org/search/ -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foun

[Wikitech-l] TechCom weekly digest 2020-08-26

org/wiki/Wikimedia_Technical_Committee/Minutes> If you prefer you can subscribe to our newsletter here <https://www.mediawiki.org/wiki/Newsletter:TechCom_Radar> -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mailin

Re: [Wikitech-l] Making breaking changes without deprecation?

y only considers code to be part of the "ecosystem" if it's on gerrit, what I proposed in my mail would mean that the Extension could be hosted anywhere, as long as it is public, and has a page on mediawiki.org -- Daniel Kinzler Principal Software Engineer, Core Platform

Re: [Wikitech-l] Making breaking changes without deprecation?

uickly fix their code (so they don't need the long deprecation), or they don't notice until things break (so they don't need the long deprecation either). -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation __

Re: [Wikitech-l] Making breaking changes without deprecation?

-public code "a little". In exchange, we should better support updating 3rd code that is public. -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] TechCom Board Review 2020-08-31

happy with it, it can go to Last Call." - DISCUSS: should we move this to last call? -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Grant merge rights on core to Martin Urbanec

dia.org/r/q/owner:martin.urbanec%2540wikimedia.cz Wikipiedia: https://cs.wikipedia.org/wiki/Wikipedista:Martin_Urbanec -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedi

Re: [Wikitech-l] Making breaking changes without deprecation?

rote it once, it's working, and they will not look at it again until it breaks. I'm not blaming them, that's what I do for "one off" code. If they are actively developing features, then sure. But then they are likely to read release notes, or tests against mast

Re: [Wikitech-l] Making breaking changes without deprecation?

lows a quick check to see > if > the deprecated code affects them without going back into their own code (which > may have been developed partly by somebody else so  just reading release notes > wouldn't clue them in that there might be a problem). -- Daniel Kinzler Principal

[Wikitech-l] TechCom weekly digest 2020-09-02

:TechCom_Radar> -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] TechCom meeting 2020-09-16

dia-office channel on freenode. <https://phabricator.wikimedia.org/T260330>. Other RFC activity: * "Parsoid Extension API": Subbu documented status of outreach with various stakeholders. <https://phabricator.wikimedia.org/T260714> -- Daniel Kinzler Principal Software E

[Wikitech-l] RFC discussion today: PHP microservice for containerized shell execution

les. Tim has been working on this for a couple of weeks, and has been updating the task in a steady monologue. Perhaps in the meeting today, we can get more eyes on the nitty gritty of the proposal. -- Daniel Kinzler Principal Software Engineer, Core Pla

Re: [Wikitech-l] Allow HTML email

Thanks Tim. This prompted me to finally switch to composing mails in HTML per default, like it's the 21st century. Am 23.09.20 um 06:45 schrieb Tim Starling: > OK done, and it seems to be working. > -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia

Re: [Wikitech-l] TechCom meeting 2020-09-23

to lack of owner > Page IDs are "mostly" stable these days, right? > > * T260714 <https://phabricator.wikimedia.org/T260714> Parsoid Extension API > o Prior to last week's meeting, Subbu described the consultation work > that has been done. >

Re: [Wikitech-l] TechCom meeting 2020-10-06

Erik asks if this is going to be generally applied to all generators > or not. > > Cheers, > Giuseppe > -- > Giuseppe Lavagetto > Principal Site Reliability Engineer, Wikimedia Foundation > > ___ > Wikitech-l mai

Re: [Wikitech-l] TechCom meeting 2020-10-06

cookies. See discussion on https://phabricator.wikimedia.org/T264631 Am 07.10.20 um 10:30 schrieb Daniel Kinzler: > > There is something I came across that I'd like to briefly discuss briefly > during the meeting: > > It would be nice if the updater could change default se

Re: [Wikitech-l] TechCom meeting 2020-10-14

g calling code to the person or group that drives the deprecation. Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] TechCom meeting 2020-10-14

t hard deprecation should happen as soon as possible after soft deprecation, and removal should happen right after the release that contained the hard deprecation. It also shifts responsibility for updating calling code to the person or group that drives the deprecation. Daniel

Re: [Wikitech-l] MediaWiki logo

Am 27.10.20 um 01:28 schrieb Denny Vrandečić: > Amir, thank you! Yes! Thank you! That was quite a ride! -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.

[Wikitech-l] TechCom topics 2020-11-04

This is the weekly TechCom board review.  Remember that there is no meeting on Wednesday, any discussion should happen via email. For individual RFCs, please keep discussion to the Phabricator tickets. Activity since Monday 2020-10-26 on the following boards: https://phabricator.wiki09media.org/

[Wikitech-l] TechCom topics 2020-11-04 (fixed)

[Re-posting with fixed links. Thanks for pointing this out Cormac!] This is the weekly TechCom board review.  Remember that there is no meeting on Wednesday, any discussion should happen via email. For individual RFCs, please keep discussion to the Phabricator tickets. Activity since Monday 2020

Re: [Wikitech-l] TechCom topics 2020-11-04 (fixed)

Am 02.11.20 um 19:24 schrieb Daniel Kinzler: > T262946 <https://phabricator.wikimedia.org/T262946> *"Bump Firefox version in > basic support to 3.6 or newer"*: last call ending on Wednesday, November 4. > Some comments, no objections. > Since we are not having a meet

Re: [Wikitech-l] TechCom topics 2020-11-04 (fixed)

Am 02.11.20 um 19:24 schrieb Daniel Kinzler: > > [Re-posting with fixed links. Thanks for pointing this out Cormac!] > > This is the weekly TechCom board review.  Remember that there is no meeting on > Wednesday, any discussion should happen via email. For individual RFCs, please &g

[Wikitech-l] TechCom RFC review meeting: mechanism for overriding configuration for browser tests

RC office hours > > No IRC discussion scheduled for next week. > > > You can also find our meeting minutes at > https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Minutes > > If you prefer you can subscribe to our newsletter here > https://www.mediawiki.org/wiki/Ne

[Wikitech-l] Proposed updates to the deprecation process

cation process, ensuring that deprecated code becomes unused quickly, without causing too much of a disturbance. Besides this, the proposal contains a number of other additions and clarifications, as described on the phab ticket and visible in the diff. I'm looking forward to hearing your tho

Re: [Wikitech-l] TechCom meeting 2020-12-02

Carly Bogen is asking for > clarity on the need for a steward.  Timo's comment > <https://phabricator.wikimedia.org/T263841#6617970> on the task indeed > seem to contradict his note from last week's grooming email.  Timo, would > you please clarify. > > > >

Re: [Wikitech-l] TechCom meeting 2020-12-02

General ParserCache service class for large "current" page-derived data > <https://phabricator.wikimedia.org/T227776> was declined by Daniel, see > his reasoning there > I'd like to note that "declined" here means that I have w

[Wikitech-l] TechCom digest 2020-12-08

need to have config controlled per-request, rather than changing config on disk. * Store WikibaseQualityConstraint check data in persistent storage T214362 <https://phabricator.wikimedia.org/T214362> o WMDE would like this to move forward.  Resourcing is not really clear. -- Daniel Ki

Re: [Wikitech-l] TechCom meeting 2020-12-16

things like tools on labs: https://www.mediawiki.org/wiki/Topic:Vzovpwgjev621dbq -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] TechCom meeting 2020-12-16

est for type safety, clarity and migration. > > >   -Niklas > ___________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org <mailto:Wikitech-l@lists.wikimedia.org> > https://lists.wikimedia.org/mailman/listinfo/wiki

Re: [Wikitech-l] TechCom meeting 2020-12-16

Am 17.12.20 um 14:25 schrieb Daniel Kinzler: > My original proposal was to change the signature of getId() to getId( $wikiId > = false ), to assert that the PageIdentity actually belongs to the wiki the > caller expects. I made a patch exploring that option: https://gerrit.wikimedi

Re: [Wikitech-l] TechCom meeting 2020-12-16

Ariel just pointed out that the original mail had the wrong link for the RFC ticket. Sorry about that The correct link to the RFC about PageIdentity is: https://phabricator.wikimedia.org/T208776 -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation

[Wikitech-l] TechCom digest 2021-01-06

oday's meeting did not have quorum attendance, so this motion will be decided on asynchronously, and adopted by next week if consensus is reached. -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wi

[Wikitech-l] Final TechCom Digest, 2020-01-20

.wikimedia.org/T259771>*: this frees up to remove about a thousand or so database patch files only needed for upgrading from very old systems. Upgrading from old versions of MediaWiki will still be possible, but have to be performed in multiple steps. -- Daniel Kinzler Principal Software

[Wikitech-l] Request for comments: A new way to do permission checks

r.wikimedia.org/T231930 3. https://meet.google.com/pjo-xtxv-oea 4. https://www.mediawiki.org/wiki/Technical_Decision_Making_Process#2_Technical_Decision_Forum 5. https://docs.google.com/document/d/1RT3mWt57RkGJdeV5kVH_eoVOBu-97w7sYheepKt6DgM/edit -- Daniel Kinzler Principal Software

[Wikitech-l] Re: Selenium tests with two instances of Mediawiki

. However, the devil is in the details... Have a look at https://phabricator.wikimedia.org/T261848 <https://phabricator.wikimedia.org/T261848> if you are interested. -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation __

[Wikitech-l] Breaking Change: Extensions Initialization via Composer Autoloading

problem in the initialization sequence. Please reply to this email if you have any concerns about this change. -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.o

[Wikitech-l] Re: ClassCrawler – extremely fast and structured code search engine

set of extensions installed (and updated). A tool very much like codesearch, but based not on regular expressions but rather on symbols and their relationships, would be very valuable to me. The question how exactly it should be build is of course open. -- Daniel Kinzler Principal So

[Wikitech-l] Re: ClassCrawler – extremely fast and structured code search engine

could be integrated with the UI, but would require a very different backend. I very much like Kunal's suggestion about LSIF. I'll reply to his mail. -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitec

[Wikitech-l] Re: ClassCrawler – extremely fast and structured code search engine

ectly that LSIF doesn't doe that?/ / PS: Sourcegraph's licensing model is a bit confusing though, seems like it's Apache for the core, and "open but not free" for some extra bits. -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___

[Wikitech-l] Breaking change to the DBPrimaryPos interface

owever, there is no base class, and the interface is marked as /stable to implement./ But there appear to be no classes in extensions that implement the interface in question, so it seems reasonable to just add the methods. -- Daniel Kinzler Principal Software Engineer, Platform Engineer

[Wikitech-l] Re: TDF is looking for community representatives

production code. There really aren't so many really active ones. Ten, maybe. -- Daniel Kinzler Principal Software Engineer, Platform Engineering Wikimedia Foundation ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe s

[Wikitech-l] Re: TDF is looking for community representatives

cessible to the general public. Currently, TDF process tracking in on phab, discussion is on google docs, and publication is on wiki. It might work better to have everything in a singe public place. -- Daniel Kinzler Principal Software Engineer, Platform En

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

ail towikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/ -- Daniel Kinzler Principal Software Engineer, Platform Engineering Wikimedia Foundation ___ Wikitech-l mailing list -- wikite

[Wikitech-l] Re: Feedback wanted: PHPCS in a static types world

dicate that a given method should be optimized for speed. Is  it possible to make phpcs smart enough that it would apply different rules if a method is marked as @hot? In that case, perhaps the use of type hints for parameters and the return type should be discouraged rather than encouraged. --

[Wikitech-l] Deprecation: directly invoking maintenance scripts

anism, and report any isses on Phabricator. Thanks, Daniel [^1] https://phabricator.wikimedia.org/T99268 [^2] with the exception over very old-school scripts that do not use the Maintenance base class and rely on CommandLineInc.php instead. -- Daniel Kinzler Principal Software Engineer, Pla

[Wikitech-l] Re: Deprecation: directly invoking maintenance scripts

k compat layer in Quibble <https://doc.wikimedia.org/quibble/> (which is written in Python): https://gerrit.wikimedia.org/r/c/integration/quibble/+/875981/6/quibble/mediawiki/maintenance.py Antoine "hashar" Musso Wikimedia Release Engineering _____

[Wikitech-l] Re: Word embeddings / vector search

ikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/ -- Amir (he/him) ___ Wikitech-l mailing list --wikitech-l@lists.wikimedia.org To unsubscribe send an email towikitech-l-le...@li

[Wikitech-l] Re: "Known languages" or similar?

es except the wiki's own language? I know I can use the interface language, but for the vast majority of users that's identical to the content language. MediaWiki core does not support this, but the Babel extension does. It offers an API, too: https://www.mediawiki.org/wiki/Extens

Re: [Wikitech-l] Open Document Format

Lars Aronsson schrieb: > Can someone explain why the Wikimedia Commons accepts uploads of > printable PDF documents (e.g. brochures) but not the editable > source version in Open Document Format (e.g. .ODT). This seems to > violate the open source principle. The reasons are of a practical natu

Re: [Wikitech-l] Open Document Format

> I'm continuing my work, and I will upload PDF files to Wikimedia > Commons, but I will keep the editable source files (ODT) offline. > > Wikimedia Commons is already full of posters and brochures in PDF, > where the editable source files are unavailable. That is sad. Yes, sad. I think everys

Re: [Wikitech-l] Upload filesize limit bumped

techman224 schrieb: > It could work. I'm no PHP expert through. > > On 21-Nov-08, at 8:10 PM, Michael Dale wrote: > > I believe php 5.2 with some minor configuration supports upload > status: > > http://www.haughin.com/2007/10/23/php-upload-progress-with-php-52-apc/ > > --michael Uh... that

Re: [Wikitech-l] Upload filesize limit bumped

> The usage of an unique upload ID ensures at their end that the progressbar > iframe always gets the right data. It refreshes using AJAX technology: > http://pastebin.com/f56b8c8f4 > I'll take a look if this might be applicable to put into MW. Yes, that seems similar to the original proposal: tra

Re: [Wikitech-l] Upload filesize limit bumped

> Sorry? You can upload multiple files in the same HTTP POST. Just add > several max_post_size). That can be done with javascript. > > Or do you mean uploading half file now and the other half on a second > connection later? I mean uploading an arbitrary number of files, without having to pick

Re: [Wikitech-l] Upload filesize limit bumped

> Does a PHP script using upload stuff get run if the file upload is complete, > or will it start while still uploading? > If not, can't you figure out the temporary name of the upload on the server > and then run ls -lh on it? It gets run only after the upload is complete. And even if not, and yo

Re: [Wikitech-l] Upload filesize limit bumped

Marco Schuster schrieb: > On Sat, Nov 22, 2008 at 4:19 PM, Daniel Kinzler <[EMAIL PROTECTED]> wrote: >>> Does a PHP script using upload stuff get run if the file upload is complete, >>> or will it start while still uploading? >>> If not, can't you figure ou

Re: [Wikitech-l] Upload filesize limit bumped

thinking about it, at the moment the best solution for multi file upload is a dedicated client. There are a couple of scripts that are hard to use, some windows-only stuff, and java-based Commonist. To get something that is easy to install and works cross-platform, how about a firefox plugin? Has

Re: [Wikitech-l] Upload filesize limit bumped

> Forcing users to use an extension isn't great as a workaround for > this, if we plan to work around it at all, since it will only affect > the tiny minority of users who a) use Firefox and b) install the > extension. If a Firefox extension is written, it would be most > sensible to have it just

Re: [Wikitech-l] Upload filesize limit bumped

Brianna Laugher schrieb: > 2008/11/22 Daniel Kinzler <[EMAIL PROTECTED]>: >> Anyway, HTTP doesn't support feedback during upload (or any feedback, >> really), >> and HTML does not offer a way for multi-file uploads (which would also be >> quite >>

Re: [Wikitech-l] Upload filesize limit bumped

Aryeh Gregor schrieb: > On Sun, Nov 23, 2008 at 8:43 AM, Daniel Kinzler <[EMAIL PROTECTED]> wrote: >> A mediawiki upload should be specific and provide >> more functionality besides picking multiple files and uploading them. Most >> importantly, it has to provide

Re: [Wikitech-l] Upload filesize limit bumped

> If the applet were appropriately signed and certified, there would be > no popup or warning to worry about. Er... this has been stated a couple of times now, and it makes me wonder. I haven't tried recently, but my impression was that an applet ALWAYS has to ask before it gets out of the sandbox

Re: [Wikitech-l] [Foundation-l] EN Wikipedia Editing Statistics

> That's scary: are there any off-site backups of the full database, > including the article text, made anywhere, other than the constantly > failing dumps? Given that Wikipedia is the Wikimedia Foundation's > principal asset, I would hope that fixing this single point of failure > would be a p

Re: [Wikitech-l] image backup and info on wikitech wiki

grin schrieb: > Even if it is, the entry on image backups is highly nonspecific and > contains a big warning about being seriously out of date. I'm not a server admin and I don't know the exact details, but as far as I know, the information there is correct in so far as there are two storage serve

Re: [Wikitech-l] Interwiki conflicts

Once again, I'd like to point the interested reader to my own take on the issue of interlanguage links: . I still believe that that would be better than a central place for managing interwikis. In a nutshell: edit locally, l

Re: [Wikitech-l] Interwiki conflicts

David Gerard schrieb: > But basically: treating interwiki links as a 1-1 relationship even > from one wiki to another is horribly unreliable, and assuming you can > go from wiki A to wiki B to wiki C with interwiki links is just not > doable reliably with robots. If you only look at language-links

Re: [Wikitech-l] download the whole wiki with one click

jida...@jidanni.org schrieb: > And, we want this to be as simple as possible for our loyal > administrator, me. I.e., use existing facilities, no cronjobs to run > dumpBackup.php (or even mysqldump, which would be giving up too much > information) and then offering a link to what they produce. dum

Re: [Wikitech-l] mwdumper ERROR Duplicate entry

Dawson schrieb: > Hello, > > I have used Special:Export at en.wikipedia to export > "Diabetes_mellitus" and ticked the box "include templates" (I'm only > really after the templates). > > The resulting XML file is 40.1mb so I decided to go with mwdumper.js > rather than Special:Import. > >

[Wikitech-l] MediaWiki developer meet-up in Berlin, April 3-5

Hello All I'm happy to announce the MediaWiki Developer Meet-Up will happen April 3.-5. in Berlin, at the c-base. The event is for everyone who works on MediaWiki, writes extensions, builds bots, writes scripts for the toolserver, or is otherwise interested in the technical aspects of Wikimedia. W

Re: [Wikitech-l] MediaWiki developer meet-up in Berlin, April 3-5

Gerard Meijssen schrieb: > Hoi, > Who says that the meet-up at FOSDEM will fail?? With people from the USA, > the Netherlands, Finland, Germany and Great Britain arriving with MediaWiki > on their mind, it can hardly be called a failed meet up. I am also quite > sure that if you want to talk about

Re: [Wikitech-l] MediaWiki developer meet-up in Berlin, April 3-5

> Exactly how Barcamp-style is this meetup gonna be? Does it include the > camping and stuff, or are we expected to sleep at hotels like at normal > conventions? Afaik, few bar camps involve actual camping :) There are loads of inexpesive hostely and modest hotels in the area. we'll put up some

Re: [Wikitech-l] Transcoding Video Contributions in Mediawiki

Platonides wrote: > Remember to add some message like 'Uploading a low-res version. Keep the > original if you want it full-res for the future.' We don't want anyone > thinking 'I uploaded this 14GB file. Now I can delete as they keep a > copy.' without fully understanding it. Some people deleted t

Re: [Wikitech-l] 403 with content to Python?

Andre Engels schrieb: > 1. Why is this User Agent getting this response? If I remember > correctly, this was installed in the early days of the pywikipediabot, > when Brion wanted to block it because it had a programming error > causing it to fetch each page twice (sometimes even more?). If that is

Re: [Wikitech-l] Article blaming

Platonides schrieb: > With all the discussion on foundation-l about contributors and > attribution, I have noted that while there're two different > implementations for blaming mediawiki articles, none of them seem to be > publically available. > There're some example results, but not the tools the

Re: [Wikitech-l] Crawling deWP

Rolf Lampa schrieb: > Marco Schuster skrev: >> I want to crawl around 800.000 flagged revisions from the German >> Wikipedia, in order to make a dump containing only flagged revisions. > [...] >> flaggedpages where fp_reviewed=1;". Is it correct this one gives me a >> list of all articles with flag

Re: [Wikitech-l] [Toolserver-l] Crawling deWP

Marco Schuster schrieb: >> Fetch them from the toolserver (there's a tool by duesentrieb for that). >> It will catch almost all of them from the toolserver cluster, and make a >> request to wikipedia only if needed. > I highly doubt this is "legal" use for the toolserver, and I pretty > much guess

Re: [Wikitech-l] [Toolserver-l] Crawling deWP

Marco Schuster schrieb: ... >> But by then, i do hope we have revision flags in the dumps. because that >> would >> be The Right Thing to use. > Still, using the dumps would require me to get the full history dump > because I only want flagged revisions and not current revisions > without the flag

Re: [Wikitech-l] Crawling deWP

Rolf Lampa schrieb: > I'd love, however, to see the flagged rev status as an attribute in one > of the tags, for example > > Regards, Naw, it's more complex than that. You can have any number of different flags. It would probably have to be foobar -- daniel __

Re: [Wikitech-l] License information

Brianna Laugher schrieb: > > I agree that it makes a lot of sense. But because it would be a big > change, I fear that unless the lead developers show great enthusiasm > for the idea, it will take a very long time to be accepted and > completed. Whereas building an "add-on" tool can be faster to g

Re: [Wikitech-l] License information

Gerard Meijssen schrieb: > Hoi, > There is RDF, there is Semantic MediaWiki. Why should one get a push and the > other not. Semantic MediaWiki is used on production websites. Its usability > is continuously being improved. No cobwebs there. SMW is of course an option for integrating metadata, but

Re: [Wikitech-l] License information

> What is a translation but another type of annotation ? > Thanks, This *Could* be modeled like that in theory. But I don't see an easy way to implement this with a low cost of transition. Basically, it would require license info to be not handled via templates at all. I don't see that happening

Re: [Wikitech-l] second-class wikis

Marcus Buck schrieb: > According to SiteMatrix we have 739 projects at the moment. There are > three master partitions for the servers: s1 for enwiki only, s2 for 19 > other projects and s3 for all the rest (that's 719 projects). > > My homewiki is one of those 719 projects. And I feel a bit neg

Re: [Wikitech-l] Lightweight Wiki?

Dawson schrieb: > Can anyone recommend a really lightweight Wiki? Preferably PHP but flat file > would be considered too. http://en.wikipedia.org/wiki/Comparison_of_wiki_software http://www.wikimatrix.org/ http://freewiki.info/ -- daniel ___ Wikitech

Re: [Wikitech-l] contribution to wikimedia.

Ankuj Gupta schrieb: > I have went thru the link that was provided. It was specifically for > Mediawiki. But my concern lies with Wikimedia. Wikimedia is a foundation that runs a lot of wikis, Wikipedia being one of them. What would you like to contribute, and how? Usually, contributions to the Wi

Re: [Wikitech-l] Backward compatibility in svn extensions

Aran schrieb: > Hi I'm just wondering what the policy is with regards to changes to > extension code in the svn in the case where the modification is > compatible only with recent versions. Shouldn't extensions be designed > to be as backward compatible as is practical rather than focussing > e

Re: [Wikitech-l] Backward compatibility in svn extensions

Gerard Meijssen schrieb: > Hoi, > Some extensions are backwards compatible however and some are not. Given > that there are plenty of people and orangisations using stable versions of > MediaWiki, how do they know and how are they to know ? > Thanks, >GerardM Never rely on it. Assume exten

Re: [Wikitech-l] Stock chart Extension

Roger Fong schrieb: > Hello, > > Trying again to see if a senior developer can grant me commit access. > Please let me know if there's any information, additional steps I need to > take to get commit access. Generally, you get commit access because people get bored from applying all the patches y

Re: [Wikitech-l] how to convert the latin1 SQL dump back into UTF-8?

jida...@jidanni.org schrieb: > Say, e.g., api.php?action=query&list=logevents looks fine, but when I > look at the same table in an SQL dump, the Chinese utf8 is just a > latin1 jumble. How can I convert such strings back to utf8? I can't > find the place where MediaWiki converts them back and fort

Re: [Wikitech-l] how to convert the latin1 SQL dump back into UTF-8?

jida...@jidanni.org schrieb: > The BLOBs are fine, it's just the VARCHARs, > `ar_title` varchar(255) character set latin1 collate latin1_bin NOT NULL > default '', > How can one convert these back to UTF-8 with a script, outside of mysql, just > for > occasional viewing of the SQL dumps outside

[Wikitech-l] MediaWiki developer meeting is drawing close

The meet-up[1] is drawing close now: between April 3. and 5. we meet at the c-base[2] in Berlin to discuss MediaWiki development, extensions, toolserver projects, wiki research, etc. Registration[3] is open until March 20 (required even if you already pre-registered). The schedule[4] is slowly bec

Re: [Wikitech-l] Importing Wikipedia XML Dumps into MediaWiki

Platonides schrieb: > O. Olson wrote: >> Does anyone have experience importing the Wikipedia XML Dumps into >> MediaWiki. I made an attempt with the English Wiki Dump as well as the >> Portuguese Wiki Dump, giving php (cli) 1024 MB of Memory in the php.ini >> file. Both of these attempts fail with

Re: [Wikitech-l] Importing Wikipedia XML Dumps into MediaWiki

> Thanks Daniel. I have tried MWDumper and the results seem different from > importDump.php i.e. the Formatting is messed up. In tracking down what I > might be doing wrong - I would prefer to do this using the native method. That sounds very *very* odd. because page content is imported as-is in

Re: [Wikitech-l] Importing Wikipedia XML Dumps into MediaWiki

O. O. schrieb: > Daniel Kinzler wrote: >> That sounds very *very* odd. because page content is imported as-is in both >> cases, it's not processed in any way. The only thing I can imagine is that >> things don't look right if you don't have all the templates i

Re: [Wikitech-l] research-oriented toolserver?

Robert Rohde schrieb: > On Mon, Mar 9, 2009 at 9:29 PM, Andrew Garrett wrote: >> On Tue, Mar 10, 2009 at 3:21 PM, K. Peachey wrote: Currently all data, including private data, is replicated to the toolserver. We could not do this with a third-party server. >>> My understanding is that t

Re: [Wikitech-l] research-oriented toolserver?

Bilal Abdul Kader schrieb: > Greetings, > We are setting up a research server at Concordia University (Canada) that is > dedicated for Wikipedia. We would love to share the resources with anyone > interested. > > In case anyone needs help setting it up, we would love to help as well. > > bilal T

<    1   2   3   4   5   6   7   >