Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Include the spoken language in the event listings - at least in the virtual events #5029

Open
szabgab opened this issue Jan 4, 2024 · 4 comments

Comments

@szabgab
Copy link
Contributor

szabgab commented Jan 4, 2024

I think it would be a good idea to include the language of the presentation in the event listings. At least for the virtual events.

I can guess that the events in the USA and Canada are in English, but what language is used at the event in Nürnberg, Germany or Wrocław, Poland?

I recently submitted one that has no physical location it is just virtual event. I tried to emphasize that it is in English and it was included in the anchor text. It is fine, but maybe this should be somehow formalized in the listings.

@szabgab szabgab changed the title Include the spoken language in the event listings - at least in the virtual events Suggestion: Include the spoken language in the event listings - at least in the virtual events Jan 4, 2024
@bennyvasquez
Copy link
Contributor

This sounds amazing, but would definitely be an increase in work required. @mariannegoldin what do you think?

@szabgab
Copy link
Contributor Author

szabgab commented Jun 8, 2024

I'd go further with this suggestion to change the virtual events to include language and time (in UTC and/or in local time) instead of the location which is really not that important for virtual events.

If you think it is a good idea, I can volunteer to handle this.

EDIT: As an experiment I tried to update the current virtual events and had to realized that showing the time in UTC would mean that an event at 7pm in California would need to be shown as an event at 4 am on the next day at UTC. It will be probably confusing. On the web site they could be shown in the local time of the viewer using a bit of JavaScript, but I don't think that's possible in the email. This sounds like too much work.

So I revert back my suggestion to show only the language instead (or in addition to) the location.

@mariannegoldin
Copy link
Contributor

@szabgab thank you so much for your contributions to TWIR and the community, and for the salient suggestion. I agree that the location/language addition for each event would be helpful for readers when deciding if they want to attend an event. Adding this info is a balancing act between added effort and sustainability for what would be a manual process on a weekly basis. I am open to suggestions!

cc: @JoelMarcey for a second opinion

Tl;dr: I think we could use an automated/AI-based solution, as making these updates will require added manual work for the events editors.

I'll answer in two parts:

  • local time: this would be useful, but would require querying the meetup API to be sustainable. I am working with some student contributors on an automation to pull this data from the Meetup API programmatically, but it is not yet finished. Otherwise, we would need to update this manually.
  • language: this is a harder one because the Event object in the Meetup API does not have a language attached. So, the language indication would need to be made through subjective interpretation, again, manually.

I could envision an approach for addressing both items above would be to create some kind of AI-based script/scrape to run over the compiled URLs, and provide the location and language for each event. It could be done with a smart agent, BabyAGI, etc. The process might be that I would have a script to run over my draft section, which would recommend the local time and language for each event. I would cross-check each suggestion before adding it. Over time, since I have a working memory of the various groups, the cross-checking would be minimal.

I welcome suggestions/ideas on how to approach this in the future.

@JoelMarcey
Copy link
Contributor

I think the only practical way to have this work is if the events themselves specified the language in some meaningful format that is easily discoverable or parsed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants