Babel: it-N, en-3, fr-1, de-1
One thing to point out about the copy that I also noted in r836183: "(s) plurals" as in "organizer(s)" should be avoided if possible. They may be good in English, but in other languages forming a plural may be slightly harder than adding an "s", and verbs would need to be conjugated differently if the subject is singular vs plural, and other parts of the sentence may need to be changed as well. See e.g. https://www.mediawiki.org/wiki/Manual:Messages_API#Switches_in_messages%E2%80%A6. If we need proper plural support for these languages, we will use the appropriate localization functions. Else, just use plural consistently.
Should this task be closed as a duplicate of T318592, or does it have a different purpose?
Tue, Sep 27
Mon, Sep 26
@vaughnwalters For testing: make sure that the schema on beta is up-to-date, and that we didn't introduce any bug in things related to registering for an event (e.g., make sure that you can still register without crashes and that your username appears in the lists of participants).
@vaughnwalters For testing, you essentially only need to ensure that the schema is up-to-date on beta, and that lists of participants are still working ("more details" dialog on event page and Special:EventDetails; possibly also the numbers shown on Special:MyEvents).
@vaughnwalters Quick note for QA: the pagination should be testable through the "list organizers of an event" endpoint, by providing the last_organizer_id parameter (that you can grab from the organizer_id field in the response).
Stalled because subtask.
This should not be worked on at this time.
Sat, Sep 24
One important update: it just occurred to me that Echo notifications via email are not guaranteed to be HTML. This can be controlled with a site-wide setting, as well as with a user preference ("Email format" in the notifications section). By itself this wouldn't be a problem, as we could adapt the message for plaintext emails by stripping some formatting. The main issue is that Echo does not tell you what format it will use, so there isn't a way to change the output depending on that preference. I think there are several possible solution, with different degrees of correctness and different time requirements:
- Stick to plaintext for now, and do something later on to enable use of HTML
- Add some quick hack to Echo that tells you what format is being used. While quick, this is really hacky. A notification model should not need to know what formatter is being used to format it.
- Refactor Echo's PresentationModel to have separate methods for different output formats (e.g., getPlaintextBody(), getHTMLBody() etc.). Maybe this could even go as far as creating separate interfaces for each output format, and let each presentation model only implement the interfaces it needs. This is potentially not only for html vs plaintext, but also web vs email vs app. Needless to say, it would take more time.
This is literally a one word change. I'll be doing this as part of the work for T316137, because we need to change the key of this message. If we wanted to keep "removed" we'd have to ask for a rename on translatewiki, but since we also want to change the content of the message, it's much easier because we don't need a rename.
Fri, Sep 23
A historical note: apparently this bug was introduced in 2009, when preferences themselves were introduced in MW core. I guess nobody uses negative offsets not rounded to the hour :)
Noting here that the timezone selector in the preferences is already broken for negative offsets, see T318455.
@vaughnwalters We're not using the new widget yet, as this was only a core change. The only place that uses the new widget right now is Special:Preferences#mw-prefsection-rendering-dateformat. There should be no change in behaviour, so you could perhaps test that the timezone selector there works the same as it did before commit 090599c048b7827b138afb7851cfcd26d3c8bd2b.
Yup, it seems to be working now, thank you :)
@ifried @gonyeahialam I created T318165 without realizing that this task already existed. Should the other one be closed as duplicate of this one? Also, maybe this one could then be renamed to "Implement ..." rather than saying "questions".
Decision: count and limit will be fixed as part of T318379. This task remains about implementing pagination.
Thu, Sep 22
I should note that the visual example above is how the Vector skins styles external links in the article body. We may be able to add icons of some kind, but it may look differently.
With that being said, we have a few options. The following were mentioned in today's meeting, but there could be more.
In reference to the above, here is how the notification would look like with minimal styling:
Wed, Sep 21
It appears this can be as simple as:© <a href="https://geocode.earth">Geocode Earth</a>
@vaughnwalters I think there isn't much for you to test here. Essentially, just make sure that if you create or edit an event, you can add, change, and remove the address without crashes or other obvious bugs. Just a quick test should suffice.
(Potential solution to this: fire the wikipage.content hook, which causes the code in checkboxShift to run again. Need to check that it's fine if the checkboxShift setup code runs more than once on the same checkbox.)
I think a possible approach would be to have getEventOrganizers() return a "continuation token" (in practice, the ceo_id of the last row in the result set), and callers could pass it as well. Maybe it could be a pass-by-ref parameter.
@vaughnwalters: you should now be able to test the final (for now) policy message when registering on beta, both on event pages and Special:RegisterForEvent.