TL;DR: Most event information in Japan already exists somewhere official, in Japanese, on a page nobody outside the town will find. Copying it by hand into an English site works for a month and then falls behind. On Yugawara Club, my bilingual guide to the hot spring town, a small daily job reads the official listings, keeps every event it has ever seen, tells me which ones still need English copy, and stops without touching anything when the source breaks. Hotels, tourism bodies, venues, and any business that republishes someone else’s schedule can use the same pattern.

Yugawara Club is a guide I founded and write myself, a sister site to this one. I lived in Yugawara from 2020 to late 2023, and the town’s events were the thing visitors asked me about most and found least. The town’s tourism association publishes a good calendar, but only in Japanese, and an English-speaking visitor searching for “what’s on in Yugawara this weekend” was unlikely to land on it. I wanted an events calendar in both languages that stayed current without me retyping it every week.

Start from the source that is already maintained

The first decision was not to compete with the town’s own calendar. The tourism association already knows when the plum festival opens, when the mikan orchards close, and which weekend the onsen district walk is on. Any calendar I maintained by hand would be a slower, less accurate copy of theirs.

So the site reads it. Every morning at 06:00 Japan time, a scheduled job fetches the official event listings and each event’s detail page, pulls out the date, time, venue, price, and contact details, and writes them into a single data file in the site’s repository. Japanese schedules are written in many ways (“10月3日(土)・4日(日)”, “12/4(金)～12/6(日)”, a market held on three separate days), so most of the code is date parsing, with tests for each format the town actually uses. If the data changed, the job commits it and the site redeploys. If nothing changed, it does nothing, so a quiet day doesn’t trigger a pointless rebuild.

I fetch politely: once a day, with a user agent that names the site and links to its About page, and only the public pages anyone can read.

Keep what the source deletes

Official calendars drop events once they’re over. That is reasonable for the town, and a loss for everyone else, because last year’s festival page is often what people find when they search for this year’s.

The job never deletes. An event that disappears from the official calendar stays in the file with the date it was last seen, so Yugawara Club builds a past-events archive the town itself doesn’t keep. Whether an event is on today, coming up this week, later, or finished is worked out in Japan time when the page is served, so a listing never says “this weekend” about something that ended on Sunday.

Be honest about what hasn’t been translated yet

Scraping gives you facts, not good English. I didn’t want machine-translated event descriptions on the site, and I didn’t want new events to stay invisible until I had time to write them up.

The compromise is explicit. A new official event appears on the site straight away, in both language versions, using the Japanese listing. The English page carries a one-line note saying it hasn’t been written up in English yet. A separate check, run after every scrape, lists every current event that still needs copy, and the job’s run summary shows the same list. When I write one up, my version replaces the raw listing. Listings with no clear date stay hidden until someone adds one, and items that aren’t really events, such as vendor lists, can be switched off.

For a business, this is the useful part. The system tells you exactly what the people who write still owe it, and it never pretends work is done when it isn’t.

Mix your own events with the official ones

Yugawara Club also lists events the town calendar doesn’t, and events I’ve written up in full. Both live in the same model. An entry I write can name the official listing it replaces, so a town event never shows up twice. Organiser names come from the official contact line, with English names for the groups that run most of the town’s events.

Each event page also gets a short plan for the rest of the day, picked by where the event is held: near the station, or up in the onsen district, with nearby baths, food, and places to stay. That turns a listing into a reason to come, which is the point of a tourism site.

One page per recurring search

Some annual events get searched for as a topic, not as a dated listing. Mikan picking is the clearest case: people search for it every autumn, not for “the 2026 edition”. So Yugawara Club has one standing page for mikan picking in Yugawara, with this season’s dates (10 October to 17 December 2026), prices, and how it works. Each year’s official listing is attached to that page rather than getting its own. The old event address permanently redirects to the guide, the sitemap leaves it out, and a test makes sure only one current event points at each guide. One page builds up search history year after year instead of a new thin page starting from zero every autumn.

Every event page carries schema.org Event data. Google’s dedicated event search experience isn’t offered in Japan at the moment (its list of supported regions doesn’t include it), so I don’t promise clients a rich result. The data still makes the date, venue, organiser, and price unambiguous to anything that reads the page.

Let it fail loudly and change nothing

On the morning of 22 October 2026, Japan time, the town’s site returned a server error when the job asked for the listings. The job stopped, marked the run as failed, and committed nothing. The live calendar kept serving the last good data, and the next morning’s run worked normally. Visitors saw nothing wrong.

That is the behaviour you want from any automation that feeds a public page. A job that quietly wrote an empty calendar after a bad fetch would have told every visitor that nothing was on in Yugawara.

What a business can take from this

The same pattern fits a ryokan or hotel group that wants an English “what’s on nearby” page, a tourism association with a Japanese-only calendar, a venue republishing promoters’ schedules, or a company whose product, price, or timetable data lives on a partner’s site:

  • Read the source that is already maintained, on a schedule, instead of retyping it.
  • Keep history the source throws away, because old pages still get searched.
  • Show untranslated or unchecked items as exactly that, with a list of what still needs work.
  • Give recurring topics one permanent page instead of a new page every year.
  • Make failures stop the job and leave the live data alone.

I build and run this kind of system for businesses in Japan. If the problem is getting events found at all, start with how to make an event in Japan easy to find in search. Operational Expansion covers adding automated feeds, bilingual publishing, and data jobs to a site that already works, and the Digital Baseline puts the accounts, website, and handover in order first. The Yugawara Club project file covers what the guide is and who it serves.

If you publish a schedule, a catalog, or a price list in Japanese and want it in English without hiring someone to retype it every week, book a Decision Session and bring the source page. I’ll tell you what can be automated, what still needs a writer, and where it will break.