User talk:SSethi (WMF)

This is the first time that I came across a meeting about language. I am not sure if today's (2023/11/17) meeting will touch on the language and scripts issue for CJK? I am mostly interested in how languages/scripts in Wikidata provide ability properly represent them? Sharing here in the event, not relevant to your meeting discussion.

Two examples below:

1) Hoy Ping-Hoping-Kaiping, etc. http://www.wikidata.org/entity/Q599514

開平(Traditional scripts, zh-Hant)

开平 (Simplified scripts, zh-Hans)

As for the transliterations

Kaiping (Mandarin Pinyin, zh-Latn-pinyin)

Hoy Ping (Cantonese, Yale) (yue-Latn) **Cantonese is part of the Wu language system that deployed the Yale transliteration in the early 20th century, I think.**

Hoiping (Cantonese, a variant to Hoy Ping, Hoipen) (yue-Latn)

K’ai-p’ing (zh-Latn-wadegile)

Khai-pêng (nan-Latn)

2) Ouyang Xiu (歐陽修) http://www.wikidata.org/entity/Q334323

literalForm "歐陽脩, 1007-1072” @lzh

"欧陽, 修, 1007-1072” @ja-Jpan

"オウヨウ, シュウ, 1007-1072” @ja-Jpan

"Oyo, Shu, 1007-1072” @ja-Latn

"歐陽修, 1007-1072" @zh-Hant

"欧阳修, 1007-1072" @zh-Hans

"Ouyang, Xiu, 1007-1072” @zh-Latn-CN (or @zh-Latn-pinyin)

"Ou-yang, Hsiu, 1007-1072” @zh-Latn-TW (or @zh-Latn-wadegile? or @zh-Latn-tongyong)

Thank you. ~~~~

Hello, thanks for your question! You can try asking here: https://www.wikidata.org/wiki/Wikidata:Community_portal. If you wish to bring more questions in future meetings, add them directly to the notes document. Keep an eye out on the Wikimedia mailing list (Wikitech-l) for an announcement about the next meeting. Alternatively, you can watch Wikimedia Language engineering/Community meetings page to receive an update.

Hello, Srishti!

I am working with AHT for a bit about changing the permanent, public display of IP addresses on wikis to automatically assigned, temporary usernames. (They'll probably look something like "User:2023-1234 5678 9" – a year plus an incrementing number; formatting/punctuation still up in the air.)

This is going to affect a lot of user scripts and tools. They're building some dev-oriented documentation at Help:Temporary accounts/How it works. I'm already in touch with some individual volunteer devs, but I wanted to see if you had ideas about people, pages, mailing lists, etc., where I could find more people who could be affected by this.

Hello @Whatamidoing (WMF), Besides the usual mailing lists/Telegram channels, for targeted outreach, it might be super useful if all the gadget and tool owners on Toolhub (over 3000 tools and 700 users) receive a message on their talk page about the change coming. A Toolhub developer could write a script to pull the information of users who could be contacted via MassMessage. Similarly, all the gadgets and user scripts out there should receive an update on their talk page so developers watching can be made aware indirectly. Top Gerrit reviewers and authors from 2022 might be the developers who can also be contacted for more ideas on the topic.

Thanks, Srishti. @SGrabarczuk (WMF) and I will look into all of your ideas.

I don't have access to the list of top Gerrit reviewers. Is there a version of that list that excludes WMF staff? (Otherwise, I could beg @Quiddity (WMF) to skim through it and remove all the usernames he recognizes.)

@Whatamidoing (WMF) That is a sorted list with unaffiliated users only, so it doesn't include WMF staff. :)

Hello! The Wikimedia Foundation is asking for your feedback in a survey. We want to know how well we are supporting your work on and off wiki, and how we can change or improve things in the future.[1] The opinions you share will directly affect the current and future work of the Wikimedia Foundation. You have been randomly selected to take this survey as we would like to hear from your Wikimedia community. To say thank you for your time, we are giving away 20 Wikimedia T-shirts to randomly selected people who take the survey.[2] The survey is available in various languages and will take between 20 and 40 minutes.

Take the survey now!

You can find more information about this project. This survey is hosted by a third-party service and governed by this privacy statement. Please visit our frequently asked questions page to find more information about this survey. If you need additional help, or if you wish to opt-out of future communications about this survey, send an email to surveys@wikimedia.org.

Thank you! --EGalvez (WMF) (talk) 21:26, 13 January 2017 (UTC)

1. ↑ This survey is primarily meant to get feedback on the Wikimedia Foundation's current work, not long-term strategy.
2. ↑ Legal stuff: No purchase necessary. Must be the age of majority to participate. Sponsored by the Wikimedia Foundation located at 149 New Montgomery, San Francisco, CA, USA, 94105. Ends January 31, 2017. Void where prohibited. Click here for contest rules.

Hello :)

I was wondering what is the best way to mention our documentation sprint in the current schedule page for the hackathon? The timing of the schedule are still a work in progress, but at least we can mention that the documentation sprint will take place during the 3 days of the event.

Thanks!

I just saw your changes to API:Opensearch. As I understand it, the preference is to have both the manual API documentation as well as the automatic API documentation. The manual documentation provides additional, version-specific information so that people can target their bots/utilities against multiple versions. In the wild, outside of Wikimedia sites, it's not uncommon to see MediaWiki versions as low as 1.20 or so, so it's important to have historical information readily available.

Thanks for your comment! We are trying to make the documentation of most popular action pages more consistent by following this template API:Documentation for all, embed the API docs as provided via Special:ApiHelp transclusion, add sample code where necessary, etc. We are changing the format only, and not removing any useful information. The deprecated parameters if any and included in the automatic API documentation, would still be shown as it is with the transclusion.

What about information about which version of MediaWiki parameters were introduced in, deprecated in, and probably most importantly, deleted in? I didn't see anything like that in the version of the page after the template was applied. Take, for example, the profile parameter of OpenSearch. If I'm designing a bot, and I'm targetting 1.25 and above, I need to know that that parameter was only introduced in 1.28, and that I can't use it (at least not without some kind of version check). On the previous version of the OpenSearch page, it was obvious at a glance. Now, it's nowhere to be found (unless I go through the page history, which isn't a tremendously useful way to find information). Similarly, if an older parameter is deleted, I need to be able to see that it's deleted at a glance, not read through a bunch of existing parameters to determine that the one I'm using is no longer there. That's why we had the API Param template in the first place, was to document all this kind of information over and above the auto-documentation.

I just had a thought on this: I'm guessing that the motivation for the change is to have the live docs being the main source of information, and that makes sense. What about putting your template first, but then keeping the ApiParam stuff underneath and renaming the section to "Parameter History" or something along those lines? That would accomplish both goals of having the live docs be the easiest to find, while the historical information remains readily available to bot developers.

You are right, and it's my fault that I didn't consider to include in the documentation template the version information about MediaWiki parameters. Thank you for sharing about this :) The parameter section was added back to the Search page by a user, and taking your suggestions into account, I ended up making modifications to their edits and then for now presenting only that information which is not covered in the automated docs here: API:Search#Parameter history. I will investigate how I can use ApiParam to display it in the way it is in the current revision.

I also saw there is a related task on Phab: T90528. I will try to figure out if it is feasible to include this information in the live docs.

That looks good. I really like your colour coding for the version information. That makes the information even more readable than it was previously. I wouldn't necessarily say you should constrain yourself to using ApiParam specifically if you have something that's better formatted. Even as one of its primary designers, I'll admit that it's very plain. Design aesthetics aren't my strong suit. :) However, you should definitely look at it at least in terms of the information it was designed to track, to figure out what kinds of details people want to have captured when it comes to parameter documentation.

On a side-note, one of the frequent issues I've seen come up among designers is that there's little documentation about what output to expect from each API module, beyond one or two examples which don't always cover every possible output. I realize that that's a lot of work for something as large as the API, but I think it's something a lot of developers would probably appreciate. Just something to think about for the future.

:) Another thought that I've -- how about we show Parameter History in a changelog format:

• v1.16: Introdced srinfo, srprop
• v1.17: Introduced nearmatch, score, titlesnippet, sectiontitle, etc.
• v1.22: Deprecated srbackend

And, then the question would be how important is to show default values and other miscellaneous info that we manually show in the parameter section? Do you've any thoughts on this?

For me, I think that would work. I can't speak for other developers. Default values and the like are certainly nice to have if they've changed over time, but in my experience, that's fairly rare in the API.

Welcome to MediaWiki.org!

Yes, welcome! This site is dedicated to documenting the MediaWiki software, the software behind many wikis, including that of Wikipedia and the Wikimedia Foundation projects.
Please, take a look at the following pages. They might prove useful to you as a newcomer here:

• Landing instructions
• Project:About
• How does MediaWiki work?
• Help:Editing pages
• Frequently asked questions
• How to contribute
• Policies

If you have any questions, please ask me on my talk page. Once again, welcome, and I hope you quickly feel comfortable here, and find this site useful documentation of the MediaWiki software.

Thanks, and regards,

Hello Srishti,

I read your message in the Wikitech-l mailing list. I asked about usecases for block based programming and you answered that you have thinked about a usecase for kids. I am interested in that usecase. What have you done regarding that topic in the past. Have you written down your ideas somewhere.

Hello! The high-level idea was to develop an experimental extension in Scratch to enable children to create information-rich and data-driven stories, animations, and games using content and data from Wikidata/Wikipedia. From a quick digging into Scratch, we found that children do try to copy content right now from Wikipedia to use it in their projects. See for reference: https://scratch.mit.edu/projects/2026251/editor/, https://scratch.mit.edu/projects/303064240/editor/. A bunch of extensions available under Scratch 3.0 allows children to do much more powerful things. For example, a Translate extension enables them to translate words between languages via Google Translate: https://en.scratch-wiki.info/wiki/Translate_Extension. There is a parallel between the idea we were thinking of implementing and this extension. But, having said this, I believe that this project would also need research besides development to understand how children use it and maybe discussion w/the Scratch team about what they think of an idea like this. I believe that Wikipedia/Wikidata has rich information that can be accessed via such an extension that children can then use to narrate stories about their favorite television stories, movie characters, musicians, etc. @Tuxology. I initially proposed this idea pre-pandemic to the Scratch conference and was accepted. But we let go when the pandemic hit. Also, the last thing is that this idea is relevant to the Scratch community and might not be relevant to the wiki world; if you decide to go further, I might be up for providing feedback on the design and conducting research w/ children in my personal capacity.

There is a discussion at [[API talk:Edit#sample code for C sharp]] which may involve you. Kindly look into it. Regards, Usernamekiran (talk) 07:16, 8 February 2022 (UTC)

Hi!

You get this message because you are an admin on a Wikimedia wiki.

When someone edits a Wikimedia wiki without being logged in today, we show their IP address. As you may already know, we will not be able to do this in the future. This is a decision by the Wikimedia Foundation Legal department, because norms and regulations for privacy online have changed.

Instead of the IP we will show a masked identity. You as an admin will still be able to access the IP. There will also be a new user right for those who need to see the full IPs of unregistered users to fight vandalism, harassment and spam without being admins. Patrollers will also see part of the IP even without this user right. We are also working on better tools to help.

If you have not seen it before, you can read more on Meta. If you want to make sure you don’t miss technical changes on the Wikimedia wikis, you can subscribe to the weekly technical newsletter.

We have two suggested ways this identity could work. We would appreciate your feedback on which way you think would work best for you and your wiki, now and in the future. You can let us know on the talk page. You can write in your language. The suggestions were posted in October and we will decide after 17 January.

Thank you. /Johan (WMF)

18:17, 4 January 2022 (UTC)

Hi Srishti,

I was looking for a way to contact the Toolhub team, but I didn't see anything on the meta pages, so I'll just tell you and hope you'll put it in the right place :-)

I saw the demo app, and I like it. However, I know that Hay's directory is a good basis but incomplete, at least as far as my tools are concerned. I recently wrote myself my own issue tracker, and as part of this, I made a list of all my tools, JavaScript on-wiki tools etc.

You can get the up-to-date list at https://magnustools.toolforge.org/buggregator/api.php?action=get_tools though you might have to filter a bit, as it also includes deactivated tools etc. It also has columns for open and closed "tickets" (issues, bug reports etc). I am going through those as time allows, so they are biased towards "open", but they might be a long-term indicator for your quality scores. I have added the "name" property from the Toolhub API where I could (I think I have all tools in your database matched).

Feel free to use this data as you see fit. Please note that the "id" field is the "stable" one, so if you add a tool of mine from there, maybe use something like "mm-tool-ID" for your "name" property.

Cheers, Magnus (I am not usually on this wiki, please drop me a line on Wikidata instead if you like)

Hello Magnus! Thanks for reaching out :) I wanted to share with you that Toolhub currently supports two ways to add tools- one via a `toolinfo.json` file that conforms to the schema https://meta.wikimedia.org/wiki/Toolhub/Data_model#Toolinfo_schema and directly via the UI. Once you are logged in, you will be able to add tools via https://toolhub-demo.wmcloud.org/add-or-remove-tools. Maybe when you get a chance, explore this feature? It will be awesome to have your tools on Toolhub!