Fri, Mar 16
I have made a change for the Wikisource extension (the CI is currently broken because the dependency on Wikibase is not setup yet). Having this feature there has two advantages:
- Do not require a configuration parameter to enable/disable this feature. We probably want it only on Wikisource.
- I am not sure that we want T180304 in WikimediaBadges and implementation of both feature are sharing some concerns (retrieving edition/work items...).
Wed, Mar 14
Tue, Mar 13
I just did a quick computation of such ratios: https://docs.google.com/spreadsheets/d/1o4zNWLesoe4OSLmfQsILW0ChprIqoP8ISVS3k3vTc-E/edit?usp=sharing
There are two spreadsheets: one talking only about claims (i.e. without taking care of references) and one only about statements with references.
It seems there are some properties with very hight quality claims we could import automatically and overall the approved/(approved+rejected) for claims is fairly good
Mon, Mar 5
@Ineuw Thank you for the report. Which editor are you using? The WikiEditor (i.e. the light blue one introduced around 2010)?
Wed, Feb 28
Sorry, I merged tasks in the wrong direction
Then in that case it would be a duplicate of T180558.
Indeed. Thank you!
Thank you @zhuyifei1999 for having a look at this task but T50625 is not solved anymore because user's databases are not available in new replica servers. So, I believe this task is relevant and should stay open.
Mon, Feb 19
I don't agree with the goal of this ticket: it is useful to have buttons on claims for two use cases:
Feb 15 2018
@matmarex have made a change that fixes this bug and it is now merged in ProofreadPage master branch. It would be great to make it live on Wikisource (backported change: https://gerrit.wikimedia.org/r/411066)
Thank you for the bug report. It's definitely not the introduction of rel=prev/next that introduced this problem but something else. See T187454
This change seems to have broken Page: pages editing interface used by Wikisource: T187454
Feb 12 2018
Feb 7 2018
Feb 5 2018
I have written a change to add rel=prev and rel=next: https://gerrit.wikimedia.org/r/#/c/408339/
Jan 28 2018
There is definitely a usability problem with the old UI pattern (only radio buttons with a bit of color). Most new contributors do not the the labels because they ave to put their mouse on top of the radios (and it's not a common pattern).
Jan 23 2018
I am concern by this task mentioning GraphQL and SPARQL as tools aiming to do same thing.
- SPARQL is great at doing complex selections (the WHERE close of the query) but is bad for data retrieval. It is possible to a table or a RDF graph. For graphs, specifying them is complex and verbose and client processing is not easy.
- GraphQL is good for data retrieval (the query specifies the data tree that should be returned, e.g. ) but is limited on the selection part. The selection features is working with a set of defined parameter, just like the MW action API is doing (doc: ). So, it is easy to limit the complexity of the requests processing.
Jan 21 2018
Jan 8 2018
Some dev summit participants are not WMF/WMDE employees, it would be great for them to open the access of the background reading documents to anyone.
Jan 2 2018
I have just done a quick investigation: the origin of this problem is that ProofreadPage overrides textarea.textSelection( 'getContents' ) too allow live preview but not the setSelection and encapsulateSelection methods that are now used by the WikiEditor find/replace system in order to work with syntax highlight. I believe that the proper fix for ProofreadPage is to overload properly these two methods.
Jan 1 2018
I just started to implement a simple GraphQL wrapper on top of the Wikibase API in order to see how it could be implemented in practice. It currently maps most of the PHP DataModel structures with an interface similar to the one of the JSON API and provides some demo queries and mutations.
Dec 29 2017
Dec 28 2017
Erreur Lua dans Module:Central-s-fr à la ligne 1709 : attempt to index global 'wikibase' (a nil value).
I do not see the relation between this error and the topic of this task. The function getEntityIdForTitle is in the mw.wikibase table and not the wikibase table and so should be called with mw.wikibase.getEntityIdForTitle(). I have updated the module: https://fr.wikisource.org/w/index.php?title=Module%3ACentral-s-fr&type=revision&diff=7132707&oldid=7131483
Dec 27 2017
Dec 26 2017
Dec 22 2017
Dec 21 2017
Dec 20 2017
Dec 14 2017
Dec 11 2017
To summary, currently mw.wikibase.getEntityIdForTitle allows to retrieve the id of the item connected to a page of the current wiki from its title as a string.
Dec 9 2017
I just did to Mediawiki:proofreadpage_index_template the change suggested by @Ankry and it seems to have fixed the problem: https://mr.wikisource.org/w/index.php?title=%E0%A4%AE%E0%A4%BF%E0%A4%A1%E0%A4%BF%E0%A4%AF%E0%A4%BE%E0%A4%B5%E0%A4%BF%E0%A4%95%E0%A5%80%3AProofreadpage_index_template&type=revision&diff=21431&oldid=627
Dec 3 2017
Duplicate of T181944
Change merged! Thank you for the bug report and the fix.
Dec 2 2017
It's rEPRP57e8b49becad27d3ce3eb3f994c131c206efd62c that merges duplicated code, removing the implementation with the bug fixed but keeping the one with the bug.
Nov 29 2017
The configuration for Index: and Page: namespaces is not properly done on cywikisource. The change https://gerrit.wikimedia.org/r/394189 to the configuration should solve this problem.
The correction for this change is now deployed. It seems to work now.
Nov 23 2017
Nov 21 2017
@Bodhisattwa I just did a null edit on the index page and it fixed the error. The correction of this bug is sadly going to roll out not this week because of Thanksgiving in the US but the week after (i.e. November 28th).
Nov 17 2017
A possible idea of root cause: the Index: page is maybe rendered at the same time as the category table from Page: pages (re)rendering. In this configuration the page status is maybe not available in the database.
Nov 16 2017
Nov 15 2017
It seems to me that is problem is now solved.
That's definitely a good idea! Let's add it to the TODO list.
Nov 14 2017
I'm fine with doing this and I believe it should be done in the same way as Commons so we have consistency.
Nov 12 2017
Nov 4 2017
Great! Let's close this task
Oct 30 2017
Oct 29 2017
A hacky way to do it is maybe to create fake "sites" per languages. We would for example have amiincubatorwiki would be a fake site that could be used for sitelink that have exactly the same configuration as the one of incubatorwiki