We also have some user agent info in civicrm_contribution_tracking now: os, os_version, browser, browser_version. Not sure how far back it goes

Okay, this should be fixed in banners now: example, change made. It was an issue even before we switched to the monthly convert dialogs, but maybe that made it a bit more obvious.

I have an idea what this is, will look into it

Okay, change on donatewiki is done.

Done, thank you!

Updated currency rates to match those on payments https://donate.wikimedia.org/w/index.php?title=MediaWiki:DonationForm.js&diff=prev&oldid=42148

Closing this since both suggestions (swapping order of name fields, and adding explanation to last name caption) were implemented on Japan forms: https://payments.wikimedia.org/index.php?title=Special%3AGravyGateway&appeal=JimmyQuote&country=JP&currency=JPY&payment_method=cc&recurring=0&gateway=gravy&uselang=ja&amount=300

In T396271#11390780, @Ejegg wrote:

@Pcoombe how hard is it to make donatewiki pass through a couple more parameters like it already does with contact_id and contact_hash? In this case, we would like it to pass checksum and contribution_recur_id to the payments form.

Jon's change is merged now. From next Tuesday we will be able to test the new skin using ?useskin=donate on production donatewiki, and I can make any required updates to the templates: I have a pretty good idea already of what needs doing.

The different color is deliberate, see the Figma file.

Previous discussion on this in T381437 and specifically T381437#10906269. Adding @ppenloglou too for info

https://donate.wikimedia.org/?country=US&hpc=10000&hpcCurrency=JPY gives the expected result for me: ignore the hpc since the currency doesn't match, and just show default USD amounts

Thanks @greg. I can manage the deploy of this since I have time tomorrow and it seems like a good learning opportunity.

This has not been resolved. Unpublished translations are now in a "CNBanner" namespace e.g. https://meta.wikimedia.org/wiki/CNBanner:FR2025_translations-iad-thank-you/en. But banner content and published translations remain in MediaWiki namespace e.g. https://meta.wikimedia.org/wiki/MediaWiki:Centralnotice-template-WikiConSeoul2025banner

We have the country name on both banners and donatewiki now. So I don't think it's needed on payments as well

For fundraising banners we use the country from mw.centralNotice.data.country (which allows us to override it with a country= url parameter for testing).

Donation forms in Bulgaria are now disabled https://donate.wikimedia.org/?country=BG, and I made an Asana task to re-enable with Euros in January

I've added to discuss in standup next week. Providing everyone agrees, it will be easy to change.

Oh wait @RKumar_WMF, are you suggesting we just disable donations from Bulgaria until January? That would suit me fine, and I can't imagine it's a lot of donations. Do we need a wider discussion before doing that?

It looks like we have payments forms for new EUR donations in Bulgaria already https://payments.wikimedia.org/index.php/Special:GravyGateway?currency=EUR&country=BG&payment_method=cc&uselang=en-gb&amount=10&opt_in=1

No longer an issue with the new homepage

Tried a patch demo (https://patchdemo.wmcloud.org/wikis/2e61fc2ecf/) and it doesn't seem to have fixed it

Legal approved this change, and I've (finally) implemented it. Diff of donatewiki javascript

I've redirected both donatewiki and banner cards to adyen

Japan cards and Google Pay traffic are now back to gr4vy on both banners and donatewiki. I updated the payments routing summary sheet

Okay, based on a conversation with @ppenloglou earlier we can include the highest previous contribution currency in the email links to donatewiki. I added a check in the javascript, if the hpcCurrency parameter doesn't match the form currency, then it won't make any changes to the amount options.

So this was for countries where we offer Paypal, but in USD instead of the local currency e.g. South Africa http://donate.wikimedia.org/?uselang=en&country=ZA. If a local currency amount is selected on donatewiki, it is passed to payments where it is automatically converted to USD. Currently we simply skip any donatewiki validation if the user selects Paypal USD, so if a user doesn't select an amount, we pass amount=null.

Seems like it would be a nice improvement, if it's not too tricky. We do also explicitly call out one-time gifts in the thank you receipt.

Just noting that we'll need a version for annual payments too

Marked this UBN because it blocks online fundraising and centralnotice admin work, but it's not affecting end users (they still see correct banners) so I'm not sure it would warrant a rollback

We agreed in standup to switch Adyen credit card, Apple Pay, and Google Pay tomorrow (7 May) at 17 UTC. I'll do this by editing donatewiki (since we need to remove the current A/B test anyway) and banner javascript. fr-tech can consider any form chooser changes later

Hi, I think Option 2 with a simple error like "Recurring donations are not supported with this payment method."

Banner templates have existed for a while now :)

Whatever the issue was, it was fixed at some point. And I was able to delete the banner

Did some searching and I can't find any banners using hideBanner alone since 2019.

The setup as described at https://www.mediawiki.org/wiki/Extension:CentralNotice#Quick_developer_setup seems to work fine

That's great, thanks @SToyofuku-WMF ! The order doesn't actually matter

Thanks! I don't do so much with TY emails any more, but remember testmeister fondly. Things it would be neat to be able to test in rough order of priority:

• different languages, countries
• different frequencies (one-time, monthly, annual)
• different emails e.g. default Thank You receipt, monthly/recurring convert
• the "draft" versions of emails

@Reedy I don't have Centralnotice admin rights on testwiki. Tried on https://meta.wikimedia.beta.wmflabs.org/ and got the following

Timing appears to line up with the train deployment to meta yesterday, which had a couple of CentralNotice related changes https://www.mediawiki.org/wiki/MediaWiki_1.44/wmf.23#CentralNotice

Confirmed that editing existing banners still works okay

An additional live preview is not needed.

Thanks, looks good to me as well now and I was able to make a donation.

https://donate.wikimedia.org/ is broken, which is used for all our non-banner fundraising. Can we get a rollback for this please?

I don't understand the request, this already exists in the "Live preview" section. Users can also click the "Preview on wiki" link to show the current banner content on a wiki page

Hi, not sure if there's somewhere better to raise this but I checked the new donate link on https://en.m.wikipedia.beta.wmflabs.org/ and it doesn't include the wmf_key=minerva which is on the current link. We need that to be able to distinguish Minerva and Vector donations on the fundraising side.

Thanks for flagging. Trustly suggested we use their hosted image in case they change the bank logos included. However it hasn't changed in the months we've been using it, and we will definitely need to host the image for banners locally anyway. So I uploaded this one to donatewiki as well, and switched our button to use the local copy.

I don't think a separate banner is needed, the standard IWD2025 banner on ar.wikipedia looks okay to me. The main <html> element will have the correct direction for the site language, and then the centralnotice will inherit from that. Not sure why that advice is in the community template.

And this is finally deployed! Thanks! As said the jquery ui elements are still light, but perfectly usable. And they really should be replaced anyway (T185913) so I don't think it matters.

I haven't seen this in a long time, and can no longer reproduce when throttling the network connection. Closing as resolved, but we should try to move away from these multiselects anyway e.g. T185913: CentralNotice: Replace date picker and multiselect widgets with OOUI widgets in Admin UI

In T90863#10623811, @Nikerabbit wrote:

This might be duplicate of T90863: BUG: CentralNotice banner translations sometimes go missing from Translate interface.

I'm confused about how any of the translations work here. Translations are all on the IWD2023 banner, but the IWD2025 banners only use the standard {{{headline}}} etc in the code so I'm not sure how they are pulling in the correct translations?