@vaughnwalters has suggested we simply leave the time off for now to get this over the line and then raise tickets once we make a final decision, I am inclined to agree.

@Udehb-WMF We have a significant number of untranslated messages, which would fall back to English on the wiki until somebody performs the translation. Can you confirm if this is acceptable and perhaps reach out to people who might be willing to translate them for us?

In T363199#9740095, @Daimona wrote:

In T363199#9739226, @cmelo wrote:

Check if all messages are translated to igbo, and if not what to do???

• The users will see the messages in English if a message is not translated to igbo

That's just how it works, nothing to do about it.

The what to do??? here is related to check if we are fine with the default fallback or if we need to translate it to Igbo before deploying it

That's just the standard way that this works. The igbo community can translate the extension on TWN whenever they want (in fact, they could've done it already). Blocking this task on the translation of the remaining 437 messages would probably push it back for quite a while.

That's not for us to decide, the ultimate arbiter for deployment is the community

Also, rather than solving for this specific case, can we try to come up with a more general rule?

@Daimona I think this is a product question, and with @ifried being away and the existing line of instruction being "Just get something sensible deployed" we can make a decision on these in her absence.

@vaughnwalters Thanks, I'll get these looked at.

Looking at the attached image, how would you suggest implementing the calendar URLs separated by a bullet? it seems like a unique layout which could cause i18n issues?

@Daimona LGTM :)

@gonyeahialam on some browsers, the side-by-side input style is not possible. Would it be acceptable to have them fall back to a vertical column as in the screenshots I sent you? Also, this design doesn't contain the "number of results" filter that is currently implemented, would you like that removed?

There is an issue with this, email client support for the current implementation is spotty at best. I am investigating alternatives.

@ifried yes, moving back

I agree with @TheresNoTime that solidarity shouldn't require justification, however for the sake of an attempt: I believe this change was prompted in the face of the ongoing situation with frwiki. see: https://bagarrosphere.fr/@photos_floues/112047957955051151

We should only redirect if the page is being accessed by an organiser. I will update AC.

Yes, I generally feel like trimming whitespace on inputs is a good idea across the board.

I think so @ifried

Yes @gonyeahialam , That is the situation as I understand it. I'm not 100% certain on the specific details of the policy though, it may just be that we can't use the google logo? I'm not sure who can provide some clarity on that point.

@gonyeahialam Apologies, yes I mean .ics

@gonyeahialam The iCal integration is a file download, without knowing what application the client is using it's not really feasible to do any form of direct integration and most calendar apps will read an ical natively anyway.

@Iflorez We have the ability to do both iCal and google, but google proves difficult as we can't use the google iconography to indicate it so may not be able to integrate both.

Pivoted this to provide new API for updating grant IDs rather than hooks

In T348343#9260290, @Daimona wrote:

In T348343#9259728, @sbassett wrote:

In T348343#9255927, @Daimona wrote:

At any rate, it doesn't really make much difference, except for the (small?) overhead of tracking an additional security patch applied in production. I just thought this could've gone through a simpler process.

Sure. It's completely fine to make this task public now if that's what you and/or other CampaignEvents developers would like to do. And then send a change set up to gerrit for master and any other relevant branches.

I think it should be fairly safe to do so, but would like to hear from @cmelo @MHorsey-WMF @VPuffetMichel.

Surely after aggregation that number should be frozen, a snapshot in time of the aggregated data?

Agreed in Design meeting 18/10/2023 - remove reference to Wikimedia but retain the rest of the message.

@ifried The message here is Wikimedia specific "In accordance with the Wikimedia foundation's terms of use", we will need a generic version.
@gonyeahialam The text is inconsistent with regular styling, the light grey is usually reserved for disabled text or help text. can we agree that it will not be grey and instead the standard black?

@gonyeahialam The AC says that this will appear when enabling registration, but does not specify if it should appear when EDITING registration. If the organiser does not accept the agreement initially, should it show on the edit form for them?