Hello all,
I am Manimaran. I am Free Software Activist and also android developer. I
try to make app for contributing Wiktionary. Which help to record audio
then upload to commons.
I share my efforts to my blog. I face some problem on development. Any one
can help me.
*Blog* :
https://manimaran96.wordpress.com/2019/01/06/spell4wiki-mobile-app-to-recor…
*Source code* : https://github.com/manimaran96/Spell4Wiki
*APK file* :
https://github.com/manimaran96/Spell4Wiki/blob/master/apk_file/spell4wiki_1…
*Issue*
- When Uploading audio I got an error message* ->
*{“error”:{“code”:”permissiondenied”,”info”:”The
action you have requested is limited to users in one of the groups:
[[Wikipedia:Autoconfirmed users|Autoconfirmed users]],
[[Wikipedia:Administrators|Administrators]], [[Wikipedia:User access
levels#Confirmed|Confirmed users]].”,”*”:”See
https://en.wikipedia.org/w/api.phpfor API usage. Subscribe to the
mediawiki-api-announce mailing list at <
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce>
for notice of API deprecations and breaking changes.”},”servedby”:”mw1226″}
- But My User name is confirmed via mail. Also Have permission to
upload. Then I don’t know why comes this type of issue.
- Also trying with other wikipedians username same error comes all of
them.
Cross-posting to wikitech-l for more community input on how extensions can
interact with CirrusSearch. :)
Thanks,
Deb
--
deb tankersley
program manager, engineering
Wikimedia Foundation
---------- Forwarded message ---------
From: David Causse <dcausse(a)wikimedia.org>
Date: Mon, Mar 18, 2019 at 9:56 AM
Subject: [discovery] Discussion around CirrusSearch extensibility
To: A public mailing list about Wikimedia Search and Discovery projects <
discovery(a)lists.wikimedia.org>
Hi,
I've put a couple pages on mw.org to start discussing about the problem we
are currently facing as to how extensions can interact with CirrusSearch
without stepping on each other toes.
To describe the problem briefly:
some extension provides additional data to the wiki structure (generally
through custom Content Handlers) and CirrusSearch itself is not aware of
the best ways to take benefits of this additional data to ameliorate
ranking or results display.
Cirrus has provided (organically) various hooks to let us build what we
have today:
- wikidata search integration for Entities, Properties & Lexemes
- search keywords
But as more and more integrations have to be done (SDoC) we need to step
back and decide on better ways to let extensions augment the search
experience.
Beware that the discussion at this stage may only be relevant to developers
who worked on these extensions. A page describes the current "query
construction" mechanism[1] (with an emphasis on parts that poses problems
at the moment) and a first list of use cases and a first set of
solutions[2].
This is just a starting point for the discussion.
Thanks for your input.
[1] https://www.mediawiki.org/wiki/Extension:CirrusSearch/Query_Construction
[2]
https://www.mediawiki.org/wiki/Extension:CirrusSearch/Query_Construction/Us…
_______________________________________________
Discovery mailing list
Discovery(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/discovery
// Sorry for cross-posting!
Reminder: Technical Advice IRC meeting this week **Wednesday 3-4 pm UTC**
on #wikimedia-tech.
Questions can be asked in English and German!
The Technical Advice IRC Meeting (TAIM) is a weekly support event for
volunteer developers. Every Wednesday, two full-time developers are
available to help you with all your questions about Mediawiki, gadgets,
tools and more! This can be anything from "how to get started" over "who
would be the best contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting:
https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
Hope to see you there!
Johanna (for the Technical Advice IRC Meeting crew)
Following approval by TechCom and WMF Interim CTO Erika Bjune, I've
moved the new Gerrit privilege policy page out of my userspace to
https://www.mediawiki.org/wiki/Gerrit/Privilege_policy
This is a merge of two pages: [[Gerrit/+2]] and [[Gerrit/Project
ownership]], with some additional changes. I've now redirected both of
those pages to the new policy page.
The main changes are:
* The wmde LDAP group, representing WMDE staff members, will be given
+2 access to mediawiki/* projects, similar to the rights given to WMF
staff members.
* The ability of ShoutWiki and Hallo Welt! to manage access to the
extensions they maintain is described and formalised.
* The ownership model for extensions is discouraged in favour of
individual requests on Phabricator. An extension owner was able to
promote developers to +2 access at their own discretion.
* The Phabricator projects for requesting access have changed. I'm in
the process of moving the tickets over.
* The revocation policy has been expanded, better describing the
present situation and making several minor changes.
-- Tim Starling
Hello. There is a regression problem, that started on this week deployment.
I can see it in group 1 from yesterday evening. I do not file a phabricator
ticket, because there is no algorithm to reproduce the problem.
>From time to time the API post query "mark this revision as read" does not
work. In these times, there is a reproducing algorithm:
1) Open Special:Watchlist.
2) Pick an unread revision.
3) Open the diff to last version, or the view mode of the page.
4) Expected: the revision, and the whole page, should be automatically
marked as read.
5) Refresh the Special:Watchlist.
6) Got: the revision remains bold.
7) Open API query for unread revisions, the relevant one is still there.
8) Try partagraphs 5-7 every 5 seconds.
9) In about twenty minutes the data is updated correctly.
I saw this yesterday at about 19:45 UTC, and it happens again just now.
Thank you.
Igal (User:IKhitron)
Hi, we are using wikimedia http api for getting pages recent changes [1]. We'd like to be able to distinguish patrolled and unpatrolled revisions and this feature is supported according to docs, but we still can't use it because of access permissions. For example if i making requests like [2] or [3] i am getting {"code": "permissiondenied", "info": "You need the \"patrol\" or \"patrolmarks\" right to request the patrolled flag."} error.
This API behaviour looks inconsistent to me, because anyone can see patrolled/unpatrolled colored markup at wikipedia revision history web pages. I think patrol right should be checked only at write (ones that mark revisions patrolled or not) API requests and not for read requests.
Is this behaviour really inconsistent and implemented that way due to technical restrictions or am i missing something? Can it be changed, so we can get patrolling information for revisions or maybe there are some workarounds exist?
[1] https://www.mediawiki.org/wiki/API:RecentChanges
[2] https://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rcprop=t…
[3] https://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rcprop=t…
Any day can be Tuesday if you really want.
* Thanks to Strainu for insightful comments on the "Backlog on bugs" thread.
* Thanks to Roan and Ed for stepping up to review major OOUI patches
this week (and to Moriel, Cormac and Matthias who proposed said patches).
--
Bartosz Dziewoński