Movatterモバイル変換

[0]ホーム
URL:

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview
List overview
Download

Wikitech-lNovember 2025

wikitech-l@lists.wikimedia.org
  • 20 participants
  • 19 discussions
Start a nNew thread
Hello everyone!We're excited to announce that the next Language Community Meeting ishappening soon - on November 28th at 16:00 UTC! If you’d like to join,simply sign up on the wiki page<https://www.mediawiki.org/wiki/Wikimedia_Language_and_Product_Localization/…>.This is a participant-driven meeting where we share updates onlanguage-related projects, discuss technical challenges in language wikis,and collaborate on solutions. For example, in our upcoming meeting, we planto hear from contributors of the Wikitongues project and FanteWikimedia Community.Got a topic to share? Whether it’s a technical update from your project, achallenge you need help with, or a request for interpretation support, we’dlove to hear from you! Feel free to reply to this message or add agendaitems to the document here<https://etherpad.wikimedia.org/p/language-community-meeting-nov-2025>.Also, we’d like to highlight that the 9th edition of the Language &Internationalization Newsletter (October 2025)<https://www.mediawiki.org/wiki/Wikimedia_Language_and_Product_Localization/…>isnow available. This newsletter provides updates from the July–September2025 quarter on new feature development, improvements in variouslanguage-related technical projects and support efforts, details aboutcommunity meetings, and ideas for contributing to projects. To stayupdated, you can subscribe to the newsletter<https://www.mediawiki.org/wiki/Newsletter:Language_and_Internationalization…>onits wiki page.Are you interested in contributing to the technical work around languagedevelopment? See a curated list of technical contribution tasks here:T407935 <https://phabricator.wikimedia.org/T407935>.We look forward to your ideas and participation at the Language CommunityMeeting. See you there!Cheers,Srishti*Srishti Sethi*Senior Developer AdvocateWikimedia Foundation <https://wikimediafoundation.org/>
1 2
0 0
Hello,On CI, if your MediaWiki extension has any dependencies, those are processed recursively. As of today, I am disabling recursion on some extensions when the CI jobs are known to pass without it.Most extensions have a small set of hard requirements (via extension.json <https://www.mediawiki.org/wiki/Manual:Extension_registration#Requirements_(…>). As developers added integration tests (which is great) more soft dependencies have been added to the tree. Due to recursion, CI can clone up to 65 extensions and, since it runs every single tests, this cause build runtime to be fairly long.Timo Tijhof wrote a very nice problem statement onhttps://phabricator.wikimedia.org/T389998. For the last few weeks I have worked on the problem to make it possible to disable recursion and went to patch several extensions to allow the removal of some dependencies.   The recursion is disabled via a recurse boolean parameter which can be checked athttps://gerrit.wikimedia.org/g/integration/config/+/refs/heads/master/zuul/… CI adds to the builds a MW_ZUUL_RECURSE parameter ("true" or "false") to expose whether recursion is enabled. You can find it in the builds parameters, for example:https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php81/lastSuc…Although I have verified the jobs still pass, there might be issues with tests from dependencies due to their own dependencies no more being cloned. In this case, those tests should be skipped. With PHPUnit this can be done using:$this->markTestSkippedIfExtensionNotLoaded( <dependency> );For example WikimediaMessages <https://www.mediawiki.org/wiki/Extension:WikimediaMessages> (which holds Wikimedia specific localization messages) depends on the cldr <https://www.mediawiki.org/wiki/Extension:CLDR> extension. WikimediaMessages is also used as a dependency by multiple extensions which do not require cldr nor do any integration testing with cldr. When recursion is disabled, those extensions no more have cldr added and that would cause WikimediaMessages test to fail. I have thus marked the test to be skipped:https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaMessages/+/1…. When CI runs for WikimediaMessages, cldr is cloned (since it is a direct dependency) and the test does run.As part of disabling recursion, there might be issues due to a missing class/extension. In this case, please file a task in Phabricator <https://phabricator.wikimedia.org/maniphest/task/edit/form/1/> against project #ci-test-error and as a subtask of T389998 <https://phabricator.wikimedia.org/T389998> mentioning the Gerrit change, the values of MW_ZUUL_RECURSE and EXT_DEPENDENCIES and a copy of the error found in the build console.cheers,Antoine "hashar" MussoWikimedia Release Engineering
1 0
0 0
Tech News 2025, week 48
by Sandister Tei 24 Nov '25

24 Nov '25
Latest *tech news<https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News>* from theWikimedia technical community. Please tell other users about these changes.Not all changes will affect you. Translations<https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/2025/48> areavailable.*Updates for editors* - Last week, the Wikimedia Search Team <https://www.mediawiki.org/wiki/Special:MyLanguage/Wikimedia_Search_Platform>recreated the "DWIM" (Do What I Mean) gadget functionality server-side, for Russian and Hebrew Wikipedias. This feature adds cross-keyboard suggestions to the standard search-box suggestions. For example, searching for *cxfcnmt* on Russian Wikipedia will now add suggestions for *счастье* ("happiness") that the user probably intended. They plan to enable this feature for other Russian and Hebrew wikis this week. [1] <https://phabricator.wikimedia.org/T408734> - Later this week, users of the "Improved Syntax Highlighting" beta feature <https://meta.wikimedia.org/wiki/Special:Preferences#mw-prefsection-betafeat…>will have syntax highlighting available in DiscussionTools <https://www.mediawiki.org/wiki/Special:MyLanguage/Help:DiscussionTools>. This requires that the "Enable editing tools in source mode" preference be set. [2] <https://phabricator.wikimedia.org/T407918> - Campaign events extension <https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Extension:CampaignEv…>– the set of tools for coordinating events and other on-wiki collaborations has now been deployed to all Wikimedia wikis. A new feature knownas Collaborative contribution <https://meta.wikimedia.org/wiki/Special:MyLanguage/CampaignEvents/Collabora…>to help organizers and participants see the impact of activities has also been added. Join the upcoming learning session <https://meta.wikimedia.org/wiki/Special:MyLanguage/Event:Connection_learnin…>to see the new feature in action and share your feedback. - View all 24 community-submitted tasks that were resolved last week <https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/Recently_resol…>. For example, the bug which stopped CodeReviewBot from working, has now been fixed. [3] <https://phabricator.wikimedia.org/T410417>*Updates for technical contributors* - Users of Wikimedia API can join a usability study to help validate the new design of Wikimedia REST API sandboxes. Interested participants should fill the recruitment survey <https://wikimediafoundation.limesurvey.net/487662>. [4] <https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…> - The MediaWiki Interfaces team is deprecating XSLT stylesheets within the Action API. Support for format=xml*&xlst={stylesheet}* will be removed from Wikimedia projects by the end of November, 2025. In addition, it will soon be disabled by default in MediaWiki release versions: v1.43 (LTS), v1.44, and v1.45. Support for XSLT stylesheets will be fully removed from MediaWiki v1.46 (expected to release between April and May 2026). [5] <https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…> - The WDQS legacy endpoint (query-legacy-full.wikidata.org) will be decommissioned at the end of December 2025, and finally closed down on 7th January 2026. After this date, users should expect requests toquery.wikidata.org that require the full graph to fail or return invalid results if they are not rewritten to use SPARQL federation. The team encourages users to ensure that tools and workflows use the supported WDQS endpoints (https://query.wikidata.org/ - Main graph orhttps://query-scholarly.wikidata.org/ - Scholarly graph). For support with migrating use cases, please review the Data Access <https://www.wikidata.org/wiki/Special:MyLanguage/Wikidata:Data_access> and Request a Query <https://www.wikidata.org/wiki/Wikidata:Request_a_query> pages for details and assistance on alternative access methods. - Detailed code updates later this week: MediaWiki <https://www.mediawiki.org/wiki/MediaWiki_1.46/wmf.4>*Tech news<https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News> preparedby Tech News writers<https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/Writers> andposted by bot<https://meta.wikimedia.org/wiki/Special:MyLanguage/User:MediaWiki_message_d…>• Contribute<https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News#contribute>• Translate<https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/2025/48> • Gethelp <https://meta.wikimedia.org/wiki/Tech> • Give feedback<https://meta.wikimedia.org/wiki/Talk:Tech/News> • Subscribe or unsubscribe<https://meta.wikimedia.org/wiki/Global_message_delivery/Targets/Tech_ambass…>.*
1 0
0 0
TLDR: Mobile devices will receive the mobile version directly on the standard domain, instead of via a redirect to the mobile subdomain. The change is live in the Beta Cluster and on test wikis, and expected to follow a train-like rollout over the next few weeks.Today, when you visit a link to a wiki (likeen.wikipedia.org), the server responds in one of two ways: a desktop page, or a redirect to the equivalent mobile URL (likeen.m.wikipedia.org). This mobile URL in turn serves the mobile version of the page from MediaWiki. Our CDN operates this way since 2011, when we enabled MobileFrontend by default. Diagram: Unified mobile routing - before and after <https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…>This redirect causes a number of problems, [2] such as: • User experience: Links shared by mobile users always display in mobile mode instead of the mode for your device, even after opt-out. • Site performance: Every Google Search result click is delayed by the redirect before displaying the article. • SEO: There is a conflict in our link graph because standard URLs redirect to mobile, and mobile sets a canonical pointer back to the standard URL. This de-indexes or mis-indexes pages in Google. T400022 <https://phabricator.wikimedia.org/T400022> • Infrastructure cost: MediaWiki sends twice as many purges to our CDN infrastructure. • Technical debt and known issues (e.g. incompatibility with OAuth). [3]Over the next few weeks, the CDN will serve the mobile version directly, without first redirecting the browser to the mobile subdomain. What is not changing • Backend code may detect mobile mode via `MobileContext->shouldDisplayMobile()`. • Frontend code may detect mobile mode via `mw.config.get('wgMFMode')`. [4] • Third-party MediaWiki sites. This is a WMF configuration change only. • Mobile requests to MediaWiki (identical HTTP host and headers). • Existing mobile URLs continue to work. • The "Desktop" opt-out footer link. • The speed of light.Backend requests unchangedThe mobile subdomain on WMF wikis is only recognised by Varnish (Wikimedia CDN). Varnish strips this "m" from the domain, activates MobileFrontend, and forwards the request to MediaWiki with the standard domain. [1]This means MediaWiki core and extensions know how to handle mobile requests on the standard domain, because that's how it already works. It also means that the change is not observable (through supported means) by backend feature code in MediaWiki, because the mobile subdomains don't exist there.What should I test?If your gadget or MediaWiki extension does not vary its behavior for mobile, or detects mobile mode using the supported mechanism listed above, then you're all set.Note that Minerva-specific or mobile-specific code in a MediaWiki extension is naturally compatible with unified mobile routing, if it was tested locally or in CI. When you install Minerva (and optionally MobileFrontend) in your dev environment, they operate without a mobile subdomain by default. • There is (probably) no mobile domain in your local dev environment. • There is no mobile domain in Patch demo. • There is no mobile domain in CI.This infrastructure change aligns WMF production with how MediaWiki and MobileFrontend work by default. This decreases the potential for bugs we have today that can be exclusively found in production (via the mobile subdomain), and resolves a backlog of existing known issues. [3]Unsupported checks in frontend codeIf a JavaScript-based feature contains a hardcoded `m.` hostname check, then this will no longer match in the future. The most likely place to find hardcoded `m.` checks is in a gadget or user script that changes its appearance or logic for mobile pages.Detecting the mobile mode in this way is unsupported and should be replaced with a supported mechanism <https://phabricator.wikimedia.org/T390923> instead. [4] An audit in April 2025 found there were 2 WMF-deployed extensions using this, which were confirmed to fallback gracefully or have since been adjusted. [5]Where can I test?The new unified mobile routing is live on these wikis: • Beta Cluster athttps://beta.wmcloud.org • test wikis athttps://test.wikipedia.org andhttps://test.wikidata.org •https://wikitech.wikimedia.org •https://office.wikimedia.org •https://www.mediawiki.orgFor other production wikis, such asen.wikipedia.org, you can preview the change today by adding `?useformat=mobile` to a URL. This activates MobileFrontend on the standard domain, like it would in the future. For example:https://en.wikipedia.org/wiki/Banana?useformat=mobile.The timeline <https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…> spans several weeks and should not require dedicated testing. If you're unsure, you can test on the pilot wikis above, or in production via the `useformat=mobile` parameter. f you find a bug with mobile toggling or another regression, please report a bug to Phabricator. If you have questions or need help with a gadget or user script, please reach out on the talk page <https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Mobile_domain_suns…>. -- Timo Tijhof🔗 Read or share this post on the web via:https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…[1]: Diagram of mobile routing before and after <https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…> [2]: Problem statement and analysis onmediawiki.org <https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…>[3]: Known issues listed in the Phabricator task <https://phabricator.wikimedia.org/T214998>[4]: Remember that mobile detection should be rare in frontend code, because most differences are between skins (Minerva vs another skin) and not MobileFrontend.[5]: Audit of unsupported m-dot checks in JavaScript <https://phabricator.wikimedia.org/T390923>
2 2
1 0

21 Nov '25
Hello, technical contributors!The MediaWiki Interfaces team is deprecating XSLT stylesheets within theAction API.Support for the format=xml&*xlst={stylesheet}* will be removed fromWikimedia projects by the end of November, 2025. In addition, it will soonbe disabled by default in MediaWiki release versions: v1.43 (LTS), v1.44,and v1.45. Support for XSLT stylesheets will be fully removed fromMediaWiki v1.46 (expected to release between April and May 2026).*=== Why are we deprecating and removing this capability? ===*Support for XSLT is generally being removed from browsers, due to a highrate of security risks and declining usage. Chrome is officially startingthe XSLT deprecation cycle<https://developer.chrome.com/docs/web-platform/deprecating-xslt>inNovember 2025, with full removal expected by November 2026. Other browsersare expected to follow. To ensure that we are not including a feature thatwill no longer be supported by browsers, we decided to end support, aswell.*=== What is the impact? === *There is currently very limited adoption of this feature across Wikimediaprojects, with usage limited to a handful of gadgets that currently rely onthis capability. We are engaging with some of the key gadget ownersdirectly, so they are aware of the change and can adjust or remove lesserused features accordingly.We also recognize that some third parties may rely on XSLT stylesheets. Inthis case, we encourage consumers to find alternative solutions as soon aspossible, given the end of XSLT support goes beyond the scope of MediaWiki.I encourage tool developers, gadget authors, and third party users toengage directly if you have questions, concerns, or if this change mayblock your ability to upgrade to future versions in a timely manner.Thanks,Halley*Halley Coplin* (she/her)Sr. Product Manager, MediaWiki InterfacesWikimedia Foundation <https://wikimediafoundation.org/>
1 0
0 0
FTP (?)
by Hipparchiaa 21 Nov '25

21 Nov '25
Madam, Sir,I am writing to you after being advised to do so. I am the email address behind the Aristoxène account on Wikimedia projects, and I have started several projects to archive/publish historical documents concerning the history of the anarchist movement. In this capacity, I have partnered with another historian of the movement who possesses an immense archival database that he has fully agreed to contribute and share to Commons.I have [started doingthis](https://commons.wikimedia.org/wiki/Category:Collection_of_Archives_An…, but I was quickly confronted with a major issue: either I maintain the original quality of the documents (so a police file of 1,000 pages, which is not that rare, is around 2 GB) but in that case I am capped by Commons and the upload speed is extremely slow (it takes +10 hours to upload); or I compile it into DjVu and in that case it is much easier and faster, but the quality of the documents (which are already handwritten and not always very easy to read even in good quality) is severely impacted, making them very difficult to use.I discussed this with a friend who does a lot of archiving work, and he told me that it would be entirely possible to request an 'FTP' at this email address; I don't know what that means, but here I am doing it—if I could upload faster it would be incredible, because right now I have about 600 GB of documents and that would take five months non-stop.Cordially,AristoxèneSent with [Proton Mail](https://proton.me/mail/home) secure email.
2 2
0 0

20 Nov '25
I'm pleased to announce the immediate availability of MediaWiki1.45.0-rc.0, the first release candidate for 1.45.0. Download links are atthe end of the e-mail. The tag has been signed and pushed to Git.This is not a final release, and should not be used for productionwebsites. Known issues are tracked in Phabricator on the release workboard[1]. As with every release of MediaWiki, a large number of changes havelanded in the six months of development (over 2300 commits since 1.44.0 wascut), and you should read over the preliminary release notes as part ofassuring yourself of areas that may have issues with your configuration,your skins, and/or your extensions.As always, please try out the release candidate in a test environment anddo report any issues that you discover. Please use the #MW-1.45-Release [2]tag in Phabricator when reporting issues specific to this release, to makesure that we find them as quickly as possible.It is expected that MediaWiki *1.45 will become final in 2 weeks*. Thisdate may slip if blockers are identified.Preliminary release notes:https://gerrit.wikimedia.org/g/mediawiki/core/+/REL1_45/RELEASE-NOTES-1.45Open Bugs:[1]https://phabricator.wikimedia.org/tag/mw-1.45-release/Bug report form:[2]https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.45-…**********************************************************************Download:https://releases.wikimedia.org/mediawiki/1.45/mediawiki-1.45.0-rc.0.tar.gzhttps://releases.wikimedia.org/mediawiki/1.45/mediawiki-1.45.0-rc.0.zipDownload without bundled extensions:https://releases.wikimedia.org/mediawiki/1.45/mediawiki-core-1.45.0-rc.0.ta…https://releases.wikimedia.org/mediawiki/1.45/mediawiki-core-1.45.0-rc.0.zipGPG signatures:https://releases.wikimedia.org/mediawiki/1.45/mediawiki-core-1.45.0-rc.0.ta…https://releases.wikimedia.org/mediawiki/1.45/mediawiki-core-1.45.0-rc.0.zi…https://releases.wikimedia.org/mediawiki/1.45/mediawiki-1.45.0-rc.0.tar.gz.…https://releases.wikimedia.org/mediawiki/1.45/mediawiki-1.45.0-rc.0.zip.sigPublic keys:https://www.mediawiki.org/keys/keys.html
1 0
0 0
Phabricator improvements
by Andre Klapper 19 Nov '25

19 Nov '25
I am excited to announce that this is an exciting announcement.Today the Wikimedia Release Engineering Team deployed a larger softwareupgrade ofhttps://phabricator.wikimedia.orgYou now better enjoy * Performance improvements: - Global fulltext Search ignores data of uninstalled Phab apps - Embedded full size image files are lazy loaded - Using DNS preconnect for our separate file domain - Faster rendering of Project Burndown tabular reports * Search user interface: - "Advanced Search" renamed to Global Search and application search - Global Search Scope dropdown: "Current Application" replaced by the actual app name; no more such option when the app does not support global fulltext search - Maniphest Task Search does not anymore show unused "Packages" and "Owners" when using typeahead in the "Subscribers" search field - Ctrl+Return in text boxes opens search results in a new tab * User Profile pages: - New "Authored Tasks" one-click menu item in sidebar - Less ambiguous menu item names in sidebar - Support for images in WebP format as avatars - (admins only): One-click menu item to view Activity Log of user - (admins only): User's Two-Factor Auth status shown on profile page * Project Workboards: - Those numbers in workboard column headers have now tooltips - Archived projects are now strike-through in navigation breadcrumbs - Automated Column Triggers: Allow setting the user who performs the move as task assignee - Thinner scrollbars in Firefox on Windows - Importing columns: No more crash when typeahead querying projects and search string is not a project name prefix - The "Move Tasks" action now requires "Can Bulk Edit Tasks" rights * Herald automated actions: - New condition "Acting user's projects" available - No more "Unknown Object (????)" for custom field values in editor * General text input: - No more text suddenly disappearing when writing {{#something:}} - Stripped surrounding whitespace when entering project or task titles - Support for "size=thumb" parameter when embedding video files * Conduit API: - Support search select fields as constraints, e.g. "Group By" in maniphest.search, project status in project.search, status and hosted in diffusion.repository.search - Improved documentation of types in transaction.search * User Preferences: - Email: No more useless "Audits" section (we uninstalled that app) - External Accounts: Shows tooltips for buttons - Multi-Factor Auth: Explains consequences of adding a second factor * Projects: - Profile images: Show maximum picture dimensions at uploading - No more "set this color to Red" message editing archived projects - No more 404 error on URLs with an alternative hashtag of a milestone * Project Report Charts: - Rotated x-axis labels for better readability - Improved line colors * Files: - Support rendering images in WebP format - List of uploads includes the timestamp, not only the date * Mobile: Support zooming on pages (e.g. when looking at image files) * Mobile: Detection of Firefox on Android (to adjust content width) * Tokens: Allow filtering given tokens by token types * Wikibugs IRC bot: Report the color of milestones correctly * (admins only) Allow changing email of bot and mailing list accounts * Numerous crasher fixes * Some accessibility improvements (ARIA labels, titles, etc) * Cleaner CSS (less noise in your browser's Developer Tools' console)Our Downstream dependency trees of tasks are athttps://phabricator.wikimedia.org/T386558 andhttps://phabricator.wikimedia.org/T393840I'd like to thank the Wikimedians BlankEclair, mainframe98, MatmaRex,pppery, taavi, valerio.bozzolan, xtex, who contributed patches to theupstream project athttps://we.phorge.it. (Hope I forgot nobody?)As usual, if you have comments or questions about Phab, please bringthem up onhttps://www.mediawiki.org/wiki/Talk:Phabricator/Help !Cheers,andre (on behalf of the Wikimedia Release Engineering Team)-- Andre Klapper (he/him) | Bugwranglerhttps://blogs.gnome.org/aklapper/
3 3
0 0
Hey everyone,I’ve noticed a lot of students (including myself) struggling with the pressure of online classes, deadlines, and quizzes — especially with platforms like Capella FlexPath, WGU, and others.If you're overwhelmed, there’s a service I recently came across called Online Classes Help. They assist with everything from discussion posts and assignments to full course completion. Super helpful for those juggling jobs or other responsibilities!Whether you need one-time help or ongoing support, this could really reduce your stress and help you maintain a good GPA. Just make sure to use it ethically — as a support tool, not a shortcut!Has anyone else tried such services? Would love to hear your experiences.Cheers! fpr more info :https://coursefpx.com/online-class-help/
2 2
0 0

19 Nov '25
Hello there, Wikimedia API users! 👋🏻*TL;DR*: We’re running a usability study to validate the new design ofWikimedia REST API sandboxes. If you’d like to take part, please fill out thisshort survey <https://wikimediafoundation.limesurvey.net/487662> (~2minutes). Thank-you gifts will be provided to participants.I’m Sarai Sanchez <https://meta.wikimedia.org/wiki/User:SSanchez-WMF> fromthe Wikimedia Foundation’s Product Design team. Together with the MediaWikiInterfaces team, we’re rethinking the presentation of REST API sandboxes.As Halley explained in a previous email, we decided to move away fromSwagger UI toward a custom interface built with Codex, Wikimedia’s designsystem (more context in Phabricator<https://phabricator.wikimedia.org/T400456>).Our goal is to create a smoother, more intuitive developer experience. Tomake sure that we’re on the right track, we’d love to get feedback aboutour design concept from technical volunteers. All perspectives will bevaluable to assess the suitability of the designs, regardless of your levelof experience working with REST APIs!*🗣️ What participation looks like*You’ll be able to choose the time for our exchange. Each session will be aone-hour video call where I’ll ask you questions about your experience withWikimedia APIs and walk through a prototype of the new REST API sandbox.I’ll ask you to perform a couple of small tasks while you share yourthoughts. As a thank-you, we’ll provide a gift to participants after thesessions.*📝 How to join*If you’re interested, please take two minutes to fill out this survey<https://wikimediafoundation.limesurvey.net/487662>. We’ll contact selectedparticipants with details about the incentive and next steps for schedulingthe session.Please feel free to reply directly to this message in case I can helpclarify any of the information shared, or if you need more information.Thank you so much for considering this and for helping us improve theexperience of everyone working with Wikimedia APIs!-- Sarai
1 0
0 0
Results per page:
[8]ページ先頭
©2009-2025 Movatter.jp