Mon, Jan 13
Sun, Jan 12
@akosiaris thanks for the patch. What are the next steps once your patch is merged?
Status update: I've requested a Gerrit repo.
Thu, Dec 26
Thanks, @jcrespo. I got my access back.
Sat, Dec 21
@bd808 Thanks for increasing the quota. I'm done porting.
Install scripts in two repositories have been updated (see above comments with Gerrit patch links). I'll try to merge them when I get my merge rights back. For now all Jessie instances have been ported to Buster.
Notes about https://recommend-alpha.wmflabs.org/missing_sections. Before upgrading I see the following error (which needs to be fixed separately):
For posterity, some notes about tool.recommendation-api.eqiad.wmflabs (as it's being used by ContentTranslation). Here's the results of pinging https://recommend.wmflabs.org/types/translation/v1/articles?source=es&target=ca&seed=Cascada%7CLuxemburgo&search=related_articles&application=CX before and after the upgrade:
Fri, Dec 20
@Pchelolo Hey, any documentation on how to move the service to node-js 10?
Wed, Dec 18
Dec 18 2019
Aug 28 2019
Aug 2 2019
@Usmanmuhd what is your OS, what version? What about MySQL and mysql connector versions? In README.org it's written that you need to install python-mysql.connector on Debian. Try figuring out the package version in Debian and installing the same in your system.
Jul 30 2019
No, you don't have to stop. I think, the system will schedule other processes between each step in your loop.
Jul 29 2019
Also maybe add a UNIQUE constraint?
Jul 28 2019
How about we pass the combined filename to the script and chunking and importing is done automatically behind the scenes? That way we don't have to worry about calculating the number of chunks ourselves. We should of course add logging and an ability continue from where we left off in case of an error.
Jul 27 2019
@Usmanmuhd I was thinking that we should split up the file into multiple files and import them one by one. But I'm curious to know if you can find a better way. Can you do some research on this? Thanks.
@leila my Gerrit +2 right have been revoked so I couldn't merge the student's patch. Could you help us find someone who can merge the patch? Thanks. Here's the patch: https://gerrit.wikimedia.org/r/#/c/mediawiki/services/recommendation-api/+/523779/
Jul 26 2019
@Usmanmuhd since we're only requesting 500 items, can you set lllimit to 500 instead? This should return all langlinks in the first request.
I think you should handle it similar to this code, i.e. llcontinue should go into the getArticlesBySeed and getArticlesByPageviews functions directly.
Jul 25 2019
Looks like so. Compare the following two URLs:
Jul 24 2019
@Usmanmuhd Looks like we're not passing all the required parameters to the API. Take a look at https://www.mediawiki.org/wiki/API:Langlinks, specifically llcontinue and lllimit. Once you pass those, you should get langlinks for results in subsequent requests after the first one.
Jul 16 2019
Jul 13 2019
@Usmanmuhd Good call. I forgot about that. So we have to make two kinds of requests to the API: by seed and by pageviews. In each case we need to make a request that fetches Wikidata IDs, then we need to make a separate request to sort these IDs by sitelink_count. We cannot phase it out because the purpose of this API is to recommend the most appropriate articles for creation, and filtering by sitelink_count was deemed appropriate when the API was created.
Jul 12 2019
@Usmanmuhd is index meaningful? I don't think it matters whether you sort it or not. It's up to you.
Actually, @Usmanmuhd I also deleted node_modules and did npm install, then the command worked. Can you try again?
Looks like some dependencies may be missing. @Mholloway I see some recent patches by you. Anything ideas how to fix the above error?
Jul 5 2019
Jun 28 2019
You don't need action=wbgetentities if you use the URL I shared. That URL gives you all the information you need to display the results.
I think you can get all the info you need in one query. Here's an example when you have a seed article:
Jun 27 2019
Your MediaWiki API URL doesn't seem to filter out the disambiguation pages (unlike WDQS) and that item (Q4077077) points to a disambiguation page.
Jun 26 2019
It was determined that two surveys cannot have the same name (as was the case for both the English and French surveys) -- as a fix, we appended "-af" to the surveys that are targeted to African countries. Though for statistical purposes, this is nice, we had avoided it because it means that readers in African countries might see survey again after answering. Dismissing or answering it the second time will completely dismiss it though and this is not different from a reader who switches browsers or clears their cache (who also could see the survey multiple times even after answering).
Wikidata has items and properties (not sure about other things). Items start with Q, and properties with P. So ?article schema:about ?item couldn't exclude Q4077077 because it's an item.
OK, let me take a look at it later today/tomorrow.
@Isaac do you want to divide up the wikis for testing? We'll have a little time to test before deploying everywhere.
Jun 25 2019
During code review we discussed disabling the button, but because it would require more coding time and because that would complicate the codebase we decided to use an alert box instead. So the user will be alerted when sending an empty response.
Jun 24 2019
Looks like the results are similar. I wonder if the MediaWiki API supports counting results rather than outputting them? Can you see if it does?
QS should be live on hewiki (labs) in about 30 mins.
Jun 22 2019
Marking tests as skipped doesn't take a lot of time and allows us not to get false alerts. How long before you can get T216750 done?
Sorry about that, @Mholloway. We'll take care of the failing tests.
Jun 20 2019
QuickSurveys may not be enabled on hewiki. I should have checked that. Will check tomorrow.
The survey will be live in about 30 mins.
The survey will be live in about 30 mins.
Thanks, I forgot about the free form text label. Can you create one more (hopefully, last) message: "Editor-gender-1-free-form-text-label"?
Jun 19 2019
@Isaac can you create two more messages: "Editor-gender-1-answer-man" and "Editor-gender-1-answer-woman" with the values "man" and "woman", respectively.
Deploying this change on 06/20, at 11:00–12:00 UTC.
Deploying this change on 06/20, at 11:00–12:00 UTC.
Jun 18 2019
The production server has a different configuration file in this repository. Maybe that's overriding the query parameter.
Thanks, I hadn't rebuilt the dependencies.
Yes, please move on to the next task.
@Usmanmuhd you're offline on IRC, so I'm replying here:
Jun 17 2019
- We'll need to deploy the changes and see if that fixes the problem in production.
Jun 14 2019
Replied in Gerrit.
OK, makes sense. Yeah, let's test this one too then. Some code is shared between internal and external surveys. Hopefully, nothing broke while we developed the free form text version. But it's a good opportunity to test external surveys.
@Isaac I see in the config that you want to test some external surveys. Aren't we going to test an internal survey with a free form text?
What you describe in T215222#5258956 looks like a bug in ruwiki. Can you create a task and describe the issue and tag it with MediaWiki-API? Hopefully the core team can help us here.
Yes, at most 500.
Jun 13 2019
OK, then, let's split up the big request into multiple small requests. Here's a similar example. Each time you'd request 50 items until you reach the total number of candidates.
Can you look into how these items are being used? If a higher sitelink_count is important, then can we request the API to return the sorted site link count? I'm worried that if we reduce the number to 50, then we may be returning lower quality results.
We need to understand why we need 500 items. If the algorithm works with 50 items, then we should use 50. If not, let's discuss it further.
It looks like the Russian Wikipedia has a lower limit. Try lowering 500 to 50.
Jun 12 2019
@Usmanmuhd I saw your messages on IRC. Let's continue the conversation here.
@Isaac, if I'm not mistaken, the change will go live on Thursday the 20th.
Onwiki documentation has been updated: https://www.mediawiki.org/w/index.php?title=Extension%3AQuickSurveys&type=revision&diff=3271984&oldid=3270271
Jun 11 2019
We don't want a situation in which the user seems to submit both a button (e.g. "Yes") and the "Other" text field. Is there a way to make it clear if they type a response in and then decide to instead go with a button, that the button is what will be submitted? Some sort of highlighting perhaps?
Jun 10 2019
The error is happening in production. When I visit this page, I'm seeing the following error:
@Usmanmuhd, any progress on this? Do you have any questions?
Jun 8 2019
@matmarex Thanks, that makes sense.
@leila and @Isaac thanks for clarifying. Since a quick survey width is restricted to 300px on desktop, one liner text input will look too narrow for multi line responses. Currently, this is how big the input size is (two lines of text can be entered there):
Jun 7 2019
Jun 6 2019
@Niedzielski would you please review the above patch? Thanks!
@Volker_E thanks for the quick reply. x.$input.focus() doesn't work either.