Name Pronunciation Guide

"A person's name is to that person the sweetest and most important sound in any language." — Dale Carnegie

A small web application that lets students record the correct pronunciation of their name ahead of a graduation ceremony, so that the person reading names aloud can practise beforehand and get it right on the day.

Graduation ceremonies involve reading hundreds of names from many linguistic backgrounds, and the person at the lectern usually meets most of those names cold. Mispronunciations are common, and for the graduating student — and their family in the audience — they sting. This tool gives students a simple way to record themselves saying their own name, and gives the reader a private page to listen through the list in advance, grouped alphabetically by surname.

It is deliberately minimal: a single recording per student, an optional phonetic spelling, and a browser-based audio player for the reader. No accounts to manage, no app to install, nothing to learn.

(Add screenshots of the student recording page and the reader's browsing page here once deployed.)

For students. A single page asks for given name, surname, and an optional phonetic spelling, then captures a short audio recording via the browser's microphone (using the standard MediaRecorder API — no plugins, works on phones and laptops). Students can listen back and re-record before submitting.

For the reader. A separate page lists all submissions grouped alphabetically by surname, with a live search filter and inline audio players. Recordings are loaded lazily, so the page stays fast even with several hundred entries.

Behind the scenes. A small Node/Express server, a SQLite database for the metadata, and audio files stored on disk as WebM/Opus. No external services, no third-party APIs, nothing to pay for.

git clone https://github.com/YOUR-USERNAME/name-pronunciation.git
cd name-pronunciation
npm install
npm start

Then open:

• http://localhost:3000/ — student recording page
• http://localhost:3000/reader.html — reader's browsing page

Microphone access requires a secure context, but localhost counts as secure, so this works without TLS during development. In production you will need HTTPS (see below).

• Node.js 18 or later (LTS recommended)
• Build tools for better-sqlite3: on Debian/Ubuntu, sudo apt-get install build-essential python3

The application is small enough to run on the cheapest tier of any cloud provider. A typical deployment uses a Linux VM running the Node process as a systemd service behind an nginx reverse proxy with a Let's Encrypt certificate.

git clone https://github.com/YOUR-USERNAME/name-pronunciation.git
cd name-pronunciation
npm install --production

Create /etc/systemd/system/name-pronunciation.service:

[Unit]
Description=Name Pronunciation Guide
After=network.target
[Service]
Type=simple
User=YOUR-USER
WorkingDirectory=/home/YOUR-USER/name-pronunciation
ExecStart=/usr/bin/node server.js
Restart=on-failure
Environment=PORT=3001
Environment=NODE_ENV=production
[Install]
WantedBy=multi-user.target

Then:

sudo systemctl daemon-reload
sudo systemctl enable name-pronunciation
sudo systemctl start name-pronunciation

Create /etc/nginx/sites-available/pronounce:

server {
 listen 80;
 server_name pronounce.example.ac.uk;
 client_max_body_size 10M;
 location / {
 proxy_pass http://127.0.0.1:3001;
 proxy_http_version 1.1;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 }
}

Enable it, then run certbot to add TLS:

sudo ln -s /etc/nginx/sites-available/pronounce /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d pronounce.example.ac.uk

TLS is not optional. Browsers refuse microphone access on plain HTTP (except on localhost), so the student page will silently fail without a valid certificate.

The application's entire state lives in two places:

• pronunciations.db — the SQLite database with names and metadata
• recordings/ — the audio files

A nightly rsync of both to a second location is enough. For example:

# /etc/cron.daily/name-pronunciation-backup
rsync -a /home/YOUR-USER/name-pronunciation/pronunciations.db \
 /home/YOUR-USER/name-pronunciation/recordings/ \
 backup-host:/backups/name-pronunciation/$(date +\%F)/

This application processes voice recordings of identifiable individuals, which constitute personal data under UK GDPR. Anyone deploying it for real use should review the following points with their institution's data protection officer.

Lawful basis. Consent is the natural basis: students choose to record themselves, and the purpose (helping the reader pronounce their name at graduation) is narrow and obvious. The student-facing page should state the purpose, the retention period, and how to request deletion before they record.

Retention. Recordings should be deleted shortly after the ceremony — a window of two to four weeks is typical, to allow for rescheduled ceremonies or post-event review. The application includes a DELETE /api/recordings/:id endpoint for individual deletion; a scheduled cleanup script is straightforward to add (see "Future work" below).

Access control. As shipped, both the student page and the reader page are open to anyone with the URL. Before deployment you should at minimum:

1. Restrict the reader page to the person reading at the ceremony, e.g. via HTTP basic auth in nginx, or an institutional SSO integration.
2. Decide on a student authentication model. Options include:
   • Trusting the URL (acceptable only for small, trusted cohorts).
   • Per-student tokens emailed individually (a reasonable middle ground for a one-off event).
   • Full SSO integration (the most robust option, but requires coordination with central IT).

The reference implementation does not include authentication in order to keep the surface area small and the code easy to audit. Adding it is straightforward; see "Future work".

Storage location. All data stays on the server you deploy to. No third-party services, no analytics, no CDN. If your institution requires data to remain within a particular jurisdiction, hosting on an appropriate VM is enough to satisfy that.

Data subject rights. Students retain the right to access, correct, or delete their recording. The simplest implementation is a contact email address on the student page; deletion via the admin endpoint takes a few seconds.

The reference implementation is intentionally minimal. Likely useful additions:

• Authentication. Per-student tokens (?t=<secret>) for the recording page; basic auth or SSO for the reader page.
• Admin interface. A simple page listing all recordings with delete buttons, for handling deletion requests.
• Scheduled cleanup. A cron job (or node-cron task) that deletes recordings older than the configured retention period.
• CSV export. For the reader to print a backup list with phonetic spellings.
• IPA helper. A small clickable IPA palette to make phonetic entry easier for students who want to provide one.
• Internationalisation. The student-facing strings are currently in English only.

Contributions are welcome. Please open an issue first to discuss anything substantial.

MIT. See LICENSE.

Built initially for use at the London School of Economics, with the hope that other institutions might find it useful too. The epigraph is from Dale Carnegie's How to Win Friends and Influence People (1936) — a book one need not endorse in its entirety to recognise the truth of that particular line.