Re: [Wikitech-l] Article geotags missing in geo_tags table for some WP languages?

[Bartosz Dziewoński]

The coordinates template/module needs to use the {{#coordinates:…}} 
parser function for the page to be geotagged.


--
Bartosz Dziewoński

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Article geotags missing in geo_tags table for some WP languages?

[Strainu]

The extension responsible for adding the data is
https://www.mediawiki.org/wiki/Extension:GeoData

The template ({{coord}}) and module (Module:Coord) on id.wp seem taken as
is from en.wp, and claims to be adding the data, although I can't find the
specific code on my phone (which means absolutely nothing).

I would check if the template or module call the parser function first. You
can also check if this is a dump problem by asking for the data through the
api.

HTH
Strainu

Pe miercuri, 7 noiembrie 2018, Martin Dittus  a scris:

> (I sent this to xmldatadumps-l yesterday but just realised that this
> might be a more suitable place.)
>
> Hallo,
>
> I'm looking at the data dumps for all Wikipedia languages and noticed
> that for some larger wikis, the geo_tags.sql.gz dump file does not
> include any geotags found in articles. Is it possible to determine why
> this is, and for which languages this is the case?
>
> For example, the geotags dump file for Indonesian (a wiki with
> >400,000 articles) is only 7kb large, and all geotags in it are from
> user pages, file uploads, or file templates, but not from articles:
> https://dumps.wikimedia.org/idwiki/20181020/
>
> Yet it doesn't take much effort to find pages that are geotagged, such
> as this one (see the infobox): https://id.wikipedia.org/wiki/London
>
> I realise that there are a number of alternative geotagging
> conventions. Does idwiki possibly use a geotagging scheme that is not
> supported by some part of this data ingestion/export process? Which
> other wikis/languages may fall in this category?
>
> I tried to find the script(s) that populate the geo_tags table from
> page content but so far had no luck, as I'm not sufficiently familiar
> with WP's software architecture; if someone can point me in the right
> direction I'd be happy to investigate myself.
>
> Many thanks!
>
> m.
>
> ___
> 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

Re: [Wikitech-l] Changes to User Blocking

[David Barratt]

We've decided it is better to *not* update User::isAllowed()
 and User::getRights()
  at this time (there are too
many edge cases to account for).

Every extension needs to deal with what a block means for their extension.
It may mean denying access, allowing access under certain conditions, or
neither.

Therefore, we recommend changing any instances of:
$user->isBlocked()
to either:
Title::userCan() // If you have the title object.
OR
$user->getBlock() && $user->getBlock()->isSitewide() // or some other
condition, if you do not have the title object.
OR
$user->getBlock() && $user->getBlock()->prevents( 'upload' ) // or some
other action that a block knows how to handle.

or some other combination. :)

Thanks!

On Mon, Nov 5, 2018 at 10:15 AM David Barratt 
wrote:

> Well, that function is also exposed externally, e. g. in the 'blocked'
>> field of the OAuth identity (what’s returned by Special:OAuth/identify).
>> What should happen to that in the future?
>
>
> For the Userinfo API   we
> added  a partial field. A
> field like this could be added, or you could use the Block::isSitewide()
> method to only inform the OAuth client that the user is blocked if they are
> blocked from everything (errr... everything except their own user talk
> page... maybe).
>
> Regardless if you expose a new flag or change the behavior of the existing
> flag, you would need to call User::getBlock() in order to determine if the
> block is sitewide or not.
> Example:
> $user->getBlock() && $user->getBlock->isSitewide()
>
> We considered changing the behavior of User::isBlocked() to only return
> true if they are sitewide blocked, but as Alex pointed out, that would
> cause blocked users to not be blocked from things that perhaps they should
> be blocked from. So we decided to fall on the side of caution.
>
> Since User::isBlocked() method doesn't really tell you anything useful
> (and as Dayllan pointed out, it hasn't for a very long time), I support
> deprecating the method. Most extensions should be calling User::isAllowed()
> or Title::userCan() instead.
>
> On Mon, Nov 5, 2018 at 9:50 AM Lucas Werkmeister <
> lucas.werkmeis...@wikimedia.de> wrote:
>
>> Well, that function is also exposed externally, e. g. in the 'blocked'
>> field of the OAuth identity (what’s returned by Special:OAuth/identify).
>> What should happen to that in the future?
>>
>> Am Mo., 5. Nov. 2018 um 15:41 Uhr schrieb Dayllan Maza <
>> dm...@wikimedia.org
>> >:
>>
>> > >
>> > > Also, are there any good reasons to continue checking
>> > > User::isBlocked()? If not, I think deprecating it would be a good
>> idea.
>> >
>> >
>> > +1 for deprecating it.
>> > I think the name of that function is misleading to begin with 'cause
>> even
>> > before "Partial Blocks" there were other actions besides edit that a
>> block
>> > could prevent (like 'sendemail').
>> >
>> >
>> > On Sun, Nov 4, 2018 at 9:39 PM Kunal Mehta 
>> wrote:
>> >
>> > > -BEGIN PGP SIGNED MESSAGE-
>> > > Hash: SHA512
>> > >
>> > > Hi,
>> > >
>> > > On 11/2/18 12:58 PM, Alex Ezell wrote:
>> > > > *tl:dr;* On a wiki with the new Partial Blocks enabled (currently
>> > > > only testwiki), if the code is checking User::isBlocked() to
>> > > > determine edit rights, it should instead check User::isBlockedFrom(
>> > > > Title ). The code could also check isBlocked() &&
>> > > > $block->isSitewide(). If it doesn’t, the code may block users that
>> > > > shouldn’t be blocked.
>> > >
>> > > Based on a quick codesearch[1], this affects a lot of extensions, and
>> > > MediaWiki core itself. It would be nice if bugs (or patches!) could be
>> > > filed against code that needs updating.
>> > >
>> > > Also, are there any good reasons to continue checking
>> > > User::isBlocked()? If not, I think deprecating it would be a good
>> idea.
>> > >
>> > > [1]
>> > >
>> https://codesearch.wmflabs.org/search/?q=-%3EisBlocked%5C(&i=nope&files=
>> > > &repos=
>> > > <
>> >
>> https://codesearch.wmflabs.org/search/?q=-%3EisBlocked%5C(&i=nope&files=&repos=
>> > >
>> > >
>> > > - -- Legoktm
>> > > -BEGIN PGP SIGNATURE-
>> > >
>> > > iQIzBAEBCgAdFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlvfrU4ACgkQUvyOe+23
>> > > /KLWYg/+LR3h0UjQwwomCba9VrnwvMYApsP7xHnZUvukMqF/mjNvKFnR1Rs/pEWj
>> > > 10IU0QMVxBB6cA47xLY9oYWoMTs6uO4qcLgJrHGxsHdaklOeaukqTZZWh4ubdhs1
>> > > KHJOoxNAfzZvD7f0IPsT1w5mlu68ehAMV5OfLH5QtqhViOBh8yCUSPn5dwpeY1k2
>> > > 28Ped42jst4U1PUCVELSf5hQe7KUCvE0xr5mcnT0rq5rta7nw9nCXeIaIQLUSP/i
>> > > ouh0ZE1vf3ScsqmM0AV2hqc2GOdtzwaMPPKXFTbP3UQjAXWYDOs7UdITLOGbQupj
>> > > JAW3vEEZEu6xd0TcvuQ1o5S9szHVxqJUOelqaZMn/w+8xOBfAQ4wcskqaEcE1Y2f
>> > > X0pneuAx473kJOfGVEv/RbAnf8Vc9hXkRoSK7OY6f0tJPYyMreWbc7H15gUVRA4X
>> > > jzcAH6VYOxxUX4trznNArmnGIisjylweZlJvTSWUawTzMNCUEieD4hWKmey8sX1r
>> > > YhQsoyuy4JkumXqY6Eu9XkVCHNQg+JZkRfGB5EudzoUAqlL5D1NhcHx+1EhaELQd
>> > > qN

[Wikitech-l] 2018-11-07 Scrum of Scrums meeting notes

[Grace Gellerman]

https://www.mediawiki.org/wiki/Scrum_of_scrums/2018-11-07

*=2018-11-07=*
== Callouts ==
* Fundraising campaigns
https://meta.wikimedia.org/wiki/CentralNotice/Calendar
* UI Standardization: RelEng, we're in need PHP 7 capable server for public
OOUI demos https://phabricator.wikimedia.org/T206046
* Release Engineering: Wikimedia Release Engineering's 1st Annual Developer
Satisfaction Survey
https://phabricator.wikimedia.org/phame/post/view/126/wikimedia_release_engineering_s_1st_annual_developer_satisfaction_survey/
* Readers Web: 14 year old bug T208909 (Thanks Tilman Bayer and Tim
Starling)
* Readers Web: Alex Hollender's very cool mobile navigation prototype
https://en.wikipedia.org/wiki/User:AHollender_(WMF)/sandbox#Advanced_mobile_nav_-_feedback
* Readers Web: SEO A/B test launch for page schemas T208755
* Readers Web: page issues A/B test complete T200792
* Follow progress for edit data lake PUBLIC dataset release on labs, will
be available via PRESTO and usable for tools such as quarry:
https://phabricator.wikimedia.org/T208752

== Audiences ==


=== Contributors ===
 Community Tech 
* Blocked by:
* Blocking:
* Updates:
**

 Anti-Harassment Tools 
* Blocked by:
* Blocking:
* Updates:
**

 Editing 
* Blocked by:
* Blocking:
** Updates:
**

 Growth 
* Blocked by: Secruity on https://phabricator.wikimedia.org/T207990 and
Services (?)  https://phabricator.wikimedia.org/T207329
* Blocking:
* Updates:
**EditorJourney schema is going live on Thursday or Monday

 Language 
* Blocked by:
* Blocking:
* Updates:
**

=== Readers ===
 iOS native app 
* Blocked by:
* Blocking:
* Updates:
**In bug-fixing mode for 6.1.1 (
https://phabricator.wikimedia.org/tag/ios-app-v6.1.1-narwhal-on-a-magic-pumpkin/),
release probably next week. 6.1.1 has fixes for login, event logging and a
bunch of UI tweaks.
**Next up, we'll work on 6.2 (
https://phabricator.wikimedia.org/tag/ios-app-v6.2/); enabling wikidata
description editing on English, user testing wikidata description editing,
logging article reading.

 Android native app 
* Blocked by:
* Blocking:
* Updates:
**Released bugfix release to production; continuing to refine interface
based on user feedback.

 Readers Web 
* Blocked by:
* Blocking:
* Updates:

** Mobile website (MinervaNeue / MobileFrontend):

*** Invest in the MobileFrontend & MinervaNeue frontend architecture
https://www.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFrontend_%26_MinervaNeue_frontend_architecture
 Collapse mobile.search.util into mobile.startup ResourceLoader module
T206027
 Increase test coverage for non-View files with 0% coverage T206698
 MobileFrontend pre-commit hooks don't work on Windows T208143
 Add TopicTitleList component T173534
 Remove unused MW configs loaded on desktop pageviews T186062

*** Page issues
https://www.mediawiki.org/wiki/Reading/Web/Projects/Mobile_Page_Issues
 A/B test complete; wrapping up subtasks and performing data analysis
T200792

*** Allow users to change their mobile skin preference T173527
*** Collect data on users who are switching from mobile to desktop T208457
*** Maintenance and bug fixes T205359 T193061 T208340

** SEO:
*** Server side split test T206868
*** Enable page schemas on the beta cluster T208763
*** Old page_random values are nonuniformly distributed T208909 (Thanks
Tilman and Tim Starling)
*** Launch A/B test for sameAs property T208755

** PDF rendering (Proton)
https://www.mediawiki.org/wiki/Reading/Web/PDF_Functionality
*** Remaining work tracked in T186748
*** Rewrite Queue to Promises T204055

*** Advanced mobile contributions
https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions
 Design working on navigation prototype:
https://en.wikipedia.org/wiki/User:AHollender_(WMF)/sandbox#Advanced_mobile_nav_-_feedback

** Design working on the community health dashboard project and
interviewing QA engineers.
** Management interviewing for apps engineering manager role.
** Post-WMTechConf/Offsite follow-ups.


 Readers Infrastructure 
* Waiting on Kartographer/JsonConfig security review (not immediately
blocked)


 Multimedia 
* Updates
** First release (multi-lingual captions) live on beta commons ... not
announcing it yet because we've bugs to work through
** Working on phase 2 (statements) and hiring

 Parsing 
* Blocked by: None
* Blocking: None
* Updates: None

 UI Standardization 
* Blocked by:
* Blocking:
* Updates:
**

== Technology ==
=== Analytics ===

* Updates:
**
** Met with security and SRE to plan best architecture to put edit data
lake data on labs via presto cluster. This is adataset that quarry can use
to answer questions that are just to hard for labs replicas, see
conversations: https://phabricator.wikimedia.org/T207321
** Will produce design document and cloud team can also take a look
**  We are about to update cloudera distro in cluster to 5.15
** Research and analytic

[Wikitech-l] Article geotags missing in geo_tags table for some WP languages?

[Martin Dittus]

(I sent this to xmldatadumps-l yesterday but just realised that this
might be a more suitable place.)

Hallo,

I'm looking at the data dumps for all Wikipedia languages and noticed
that for some larger wikis, the geo_tags.sql.gz dump file does not
include any geotags found in articles. Is it possible to determine why
this is, and for which languages this is the case?

For example, the geotags dump file for Indonesian (a wiki with
>400,000 articles) is only 7kb large, and all geotags in it are from
user pages, file uploads, or file templates, but not from articles:
https://dumps.wikimedia.org/idwiki/20181020/

Yet it doesn't take much effort to find pages that are geotagged, such
as this one (see the infobox): https://id.wikipedia.org/wiki/London

I realise that there are a number of alternative geotagging
conventions. Does idwiki possibly use a geotagging scheme that is not
supported by some part of this data ingestion/export process? Which
other wikis/languages may fall in this category?

I tried to find the script(s) that populate the geo_tags table from
page content but so far had no luck, as I'm not sufficiently familiar
with WP's software architecture; if someone can point me in the right
direction I'd be happy to investigate myself.

Many thanks!

m.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l