Re: [Wikitech-l] People with knowledge of English swear words needed :o
About swears in English language, sorry I can't help but I'm very good at Persian :D, We have an abuse filter about Persian swears which is hidden from public https://fa.wikipedia.org/wiki/%D9%88%DB%8C%DA%98%D9%87:%D9%BE%D8%A7%D9%84%D8%A7%DB%8C%D9%87_%D8%AE%D8%B1%D8%A7%D8%A8%DA%A9%D8%A7%D8%B1%DB%8C/4 And It works pretty good, So If you need to i18n huggle, this page will be a good help Best On Thu, Sep 19, 2013 at 8:59 PM, Neil Harris n...@tonal.clara.co.uk wrote: On 19/09/13 10:35, Petr Bena wrote: Are you good in swearing? WE NEED YOU Huggle 3 comes with vandalism-prediction as it is precaching the diffs even before they are enqueued including their contents. Each edit has so called score which is a numerical value that if higher, the edit is more likely a vandalism. If you want to help us improve this feature, it is necessary to define a score words list for every wiki where huggle is about to be used, for example on English wiki. Each list has following syntax: (see https://en.wikipedia.org/w/**index.php?title=Wikipedia:** Huggle/Configdiff=573615259**oldid=573615075https://en.wikipedia.org/w/index.php?title=Wikipedia:Huggle/Configdiff=573615259oldid=573615075 ) score-words(score): list of words separated by comma, can contain newlines but comma must be present example score-words(200): these, are, some, words, which, presence, of, increases, the, score, each, word, by, 200, [[en:User:/DeltaQuad/UAA/**Blacklist]] contains a fairly comprehensive overview of English-language profanity and general trash-talk formatted as regexps, mixed in with other non-sweary blocking patterns that are specific to that blacklist's needs. Neil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Amir ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] extension unit tests were incorrect for last couple days
Hello, On Sep 19th around 1am UTC, I have updated the Jenkins jobs running the unit tests for MediaWiki extensions. I did a mistake that caused Jenkins to fetch the extension to a directory named according to its Gerrit project name (ie prefixed with mediawiki/). That caused the jobs to no more be running the code submitted via Gerrit but an old copy left in extensions/Foobar. The issue is now resolved. You might find some patches are now failing when they used to be fine, that is because they are actually tested now! Danke, Tobias und addshore, dass ihr dieses Problem gefunden habt. =) Change causing the issue: https://gerrit.wikimedia.org/r/#/c/84918/ The fix: https://gerrit.wikimedia.org/r/#/c/85202/ -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Individual Engagement Grants: deadline approaching
The deadline to present proposals for Individual Engagement Grants is September 30. https://meta.wikimedia.org/wiki/Grants:IEG Individual developers and small teams still have a chance to present proposals for tech projects supporting the Wikimedia mission and strategic priorities. If you have a technical proposal with a budget below USD $30,000 we want to hear about it! If you have the time and skills but you are missing a proposal, an option is to check https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects Projects listed in that age that look like good candidates include Wikidata 3rd party client https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#3rd_party_client New media types supported in Commons https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#New_media_types_supported_in_Commons MediaWiki-Bugzilla extension https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#MediaWiki-Bugzilla_extension UploadWizard: OSM map embedding https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#UploadWizard:_OSM_map_embedding Ranking articles by Pageviews for Wikiprojects and Task Forces in Languages other than English https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Ranking_articles_by_Pageviews_for_Wikiprojects_and_Task_Forces_in_Languages_other_than_English -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Analytics] [WikimediaMobile] Mobile stats
Oh awesome! Glad y'all found it! On Sep 19, 2013, at 5:01 PM, Adam Baso ab...@wikimedia.org wrote: +Analytics On Thu, Sep 19, 2013 at 1:57 PM, Adam Baso ab...@wikimedia.org wrote: A run on yesterday's valid Wikipedia Zero hits showed that user agents NOT supporting HTML (i.e., only supporting WAP) is only 0.098 - 0.108 *percent*. Assuming a bunch of complaints don't come in (e.g., I'm getting tag soup!, as Max might say), I think we could make a reasonable case to stop supporting WAP through the formal channels (blog, mailing list(s), etc.). -Adam On Tue, Sep 17, 2013 at 1:11 PM, Arthur Richards aricha...@wikimedia.org wrote: That's awesome - thanks Max and Adam; it's great to see the last vestiges of X-Device finally disappear! On Tue, Sep 17, 2013 at 1:07 PM, Max Semenik maxsem.w...@gmail.com wrote: After looking at Varnish VCL with Adam, we discovered a bug in regex resulting in many phones being detected as WAP when they shouldn't be. Since the older change[1] simplifying detection had also fixed this bug, Brandon Black deployed it and since today the usage share of WAP should seriously drop. We will be monitoring the situation and revisit the issue of WAP popularity once we have enough data. [1] https://gerrit.wikimedia.org/r/83919 On Tue, Sep 10, 2013 at 4:39 PM, Adam Baso ab...@wikimedia.org wrote: Thanks. 7-9% of responses on Wikipedia Zero being WAP is pretty substantial. On Tue, Sep 10, 2013 at 2:01 PM, Andrew Otto o...@wikimedia.org wrote: These zero.tsv.log* files to which I refer seem to be, basically Varnish log lines that correspond to Wikipedia Zero-targeted traffic. Yup! Correct. zero.tsv.log* files are captured unsampled and based on the presence of a zero= tag in the X-Analytics header: http://git.wikimedia.org/blob/operations%2Fpuppet.git/37ffb0ccc1cd7d3f5612df8779e9a3bdb69066b2/templates%2Fudp2log%2Ffilters.oxygen.erb#L10 Do I understand correctly that field as Content-Type? Yup again! The varnishncsa format string that is currently being beamed at udp2log is here: http://git.wikimedia.org/blob/operations%2Fpuppet.git/37ffb0ccc1cd7d3f5612df8779e9a3bdb69066b2/modules%2Fvarnish%2Ffiles%2Fvarnishncsa.default -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Mobile-l mailing list mobil...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Analytics mailing list analyt...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RfC update: LESS stylesheet support in core
On Thu, Sep 19, 2013 at 2:19 PM, C. Scott Ananian canan...@wikimedia.orgwrote: @dan: the particular less isn't very powerful issues I'm concerned about are the ones solved by compass. As is well-known, there is no equivalent to compass for less, and is not likely every to be, since less can not express the transformations required. Compass uses ruby code to do this w/ sass. For example, https://github.com/chriseppstein/compass/blob/stable/lib/compass/sass_extensions/functions/gradient_support.rbis the code in compass in order to generate clean gradient specifications that work with all major browsers (including synthesizing SVG background images where required). http://lesshat.com/#gradient implements it, except it adds custom functions in JS to handle SVG generation. We could trivially implement an equivalent in PHP using http://leafo.net/lessphp/docs/#custom_functions. There is already a patch to extend LESS to provide an embed() function that can generate data URIs from image file references. https://gerrit.wikimedia.org/r/#/c/85143/. When two tools share a use-case and vie for the same user-base (as is the case with LESS and Sass) there is a natural tendency to exaggerate the importance of esoteric features that set them apart. There are things that LESS handles more gracefully than Sass, too. But I expect us to be appropriately conservative in using these features anyhow. The biggest gains to be had from using a CSS preprocessor tend to come from the most basic features: giving comprehensible names to literal values (e.g. @wikimediaBlue instead of #006699), and having shorthand notations for generating standard interface patterns. I personally think it'd be unfortunate for this current effort to collapse over such considerations, but I'm obviously biased. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Language Engineering IRC Office hour on September 25, 2013 at 1700 UTC
[Cross-posted] Hello, The Wikimedia Language Engineering team will be hosting an IRC office hour on Wednesday, September 25, 2013 between 17:00 - 18:00 UTC. (See below for timezone conversion and other details.) We will be talking about some of our projects that are in development, a short round up from Google Summer of Code and then taking questions for the remaining time. If there are things that you would like to bring to our attention then this would be a good time to do so. Questions can also be sent to me directly before the event. See you there! Thanks Runa === Event Details === What: WMF Language Engineering Office hour When: September 25, 2013 (Wednesday). 1700-1800 UTC http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130925T1700 Where: IRC Channel #wikimedia-office on FreeNode -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RfC update: LESS stylesheet support in core
On Fri, Sep 20, 2013 at 2:35 PM, Ori Livneh o...@wikimedia.org wrote: I personally think it'd be unfortunate for this current effort to collapse over such considerations, but I'm obviously biased. Oh, I certainly agree. For my part, I'm satisfied that the LESS/Sass/stylus issues have been adequately thought through (maybe some of this can make it back into the RfC). The http://leafo.net/lessphp/docs/#custom_functions stuff looks very promising, it probably should be explicitly mentioned in any LESS for MW docs we write. I look forward to seeing the @import guidelines as well. --scott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RfC update: LESS stylesheet support in core
On Fri, Sep 20, 2013 at 12:53 PM, C. Scott Ananian canan...@wikimedia.orgwrote: On Fri, Sep 20, 2013 at 2:35 PM, Ori Livneh o...@wikimedia.org wrote: I personally think it'd be unfortunate for this current effort to collapse over such considerations, but I'm obviously biased. Oh, I certainly agree. For my part, I'm satisfied that the LESS/Sass/stylus issues have been adequately thought through (maybe some of this can make it back into the RfC). The http://leafo.net/lessphp/docs/#custom_functions stuff looks very promising, it probably should be explicitly mentioned in any LESS for MW docs we write. I look forward to seeing the @import guidelines as well. --scott Heartily agree as well. I alluded to this in my longer answer. Basically Stylus/SASS do seem to be slightly ahead of LESS but it's a vanishing difference and meaningLESS over the long term. The biggest gains to be had from using a CSS preprocessor tend to come from the most basic features This I think is a most astute point from Ori. It's why I made the analogy to Coco. I don't and never will use any of the complicated crazy Coco constructs. But writing class LineNode extends TimeseriesNode instead of all the JS boilerplate for classes and inheritance is good. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Deployment highlights for the week of Sept 23rd
Hello! Here's what's coming up, deployment-wise, next week! As always, full schedule here: https://wikitech.wikimedia.org/wiki/Deployments == Monday == * MediaWiki 1.22wmf18 to all non-wikipedia project sites * WikiData will be enabled on Wikimedia Commons (interwiki links) * CirrusSearch (the new search backend) will be turned on as the default search backend for Italian Wikitionary and enabled as a secondary backend for English Wikisource and Catalan Wikipedia. == Tuesday == * CirrusSearch will be enabled on the set of closed wikis (eg: old Wikimania wikis). == Thursday == * MediaWiki 1.22wmf18 will be deployed to all Wikipedias * MediaWiki 1.22wmf19 will be deployed to the set of test wikis plus mediawiki.org Have a good weekend! Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] AbuseFilter error codes and MobileFrontend
Ugh, that was meant to go to wikitech-l too... On 09/20/2013 03:38 PM, Juliusz Gonera wrote: Hi, A bit of background: Not long ago we launched mobile editing. Soon after that we discovered that the mobile editor fails on many wikis because we hadn't thought think about AbuseFilter support. We're trying to fix this now. Statistics about the most frequent AbuseFilter error codes we're getting: https://mingle.corp.wikimedia.org/projects/mobile/cards/1162 Related bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=52049 After getting some initial information from legoktm, my thoughts are: * Probably no changes to AbuseFilter are necessary and we should implement everything in MobileFrontend. * We should display the warning message (edit.warning in API response) for all codes (edit.code in API response) that start with abusefilter-warning* and allow the user to resubmit. * We should display the disallow message (edit.warning in API response) for abusefilter-disallow and not allow the user to resubmit. * We should display edit.warning message if present or a general one and not allow the user to resubmit for all the other error codes (until now we've got abusefilter-blanking, abusefilter-blank, abusefilter-imza, abusefilter-blocked-display and abusefilter-autobiography, but they don't happen too often). Are my assumptions correct? Any thoughts or suggestions? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
