If you're the one who'll be doing the localisation work, there's a good chance your company should be paying for this course, not you. Most companies have a training budget, and plenty of managers would rather spend a little on training than pay for the same bug in eight languages.
This page gives you an email you can send as it is, or edit to suit your team. It also answers the questions managers usually ask. Fill in the parts in [square brackets], and cut anything that doesn't apply to you.
Before you send it
A few things make the request easier to approve:
- Tie it to real work. If there's a launch, a big customer asking for another language, or a pile of localisation bugs, mention it. "We're launching in Germany in March" gets a yes faster than "this looks useful".
- Be honest about what it is. It's a book for developers, with a video course on the way. It won't translate your product for you. It will help you avoid building the parts that are expensive to fix later.
- Check your company's process first. Some companies want a request form, a purchase order or a supplier set up before anyone buys anything. Ask whoever handles that before you email your manager, so you can say which route you'll use.
The email
Subject: Training request: Hello World, a localisation course for developers
Hi [manager's name],
I'd like to use [our training budget / my learning allowance] for Hello World, a book on localising software. It's written for developers who do the work, and it isn't tied to one framework or language. It costs [price] for [one person / a team licence for N people].
Why now. [We're planning to launch in (market) in (month) / A customer has asked for (language) / We've had (number) bugs this quarter with dates, currencies or translations.] Localisation touches more than the words: dates, money, addresses, plurals, layout, emails and payments. Most of the cost comes from fixing those after launch, in languages nobody on the team reads.
What it covers.
- Locales, and working out which language, region and currency each user wants
- Getting text into translation files, with plurals, gender and placeholders done properly
- Working with translators, including AI first passes and human review in the product
- Numbers, money, dates, timezones, addresses and people's names
- Layout, right-to-left languages, URLs and SEO, emails and other output outside the browser
- Testing, keeping it working after launch, and the business side: costs, markets and measuring results
What we'd get out of it.
- Fewer localisation bugs. Each topic ends with a checklist of the mistakes that cause them, and how to test for them.
- AI skills that audit our codebase. The course includes skills for AI coding agents [like Claude Code, Cursor and Codex]. The audit skill searches a codebase for hard-coded text, hand-built dates and prices, money stored as floats, US-shaped forms and other common problems, and reports each one with its file, line and the chapter that explains it. It reports rather than fixes. That gives us a list of what needs changing and a rough estimate before we commit to a date.
- A step-by-step playbook. A phase-by-phase plan for localising an existing app, with a master checklist we can copy into [Linear / Jira / our tracker].
- Templates. A translator brief, style guide, glossary, source string guidelines, vendor questions, locale proposal and review checklist, ready to copy into [Notion / Google Docs].
- A shared vocabulary. [If it's a team licence: everyone on the team, plus product and design, works from the same rules, so we stop relearning the same lessons in code review.]
Time. Each chapter stands on its own, so I'd start with the ones that matter for [our next project] and work through the rest over [timeframe]. I'd share [a summary / the audit results / a short talk] with the team afterwards.
It comes with an invoice, and there's a 30-day money-back guarantee. Happy to send any details you need.
Thanks, [Your name]
If you're asking for a team licence
Swap the first paragraph for this:
I'd like us to buy a team licence for Hello World, a book on localising software, for [number] people on [team name]. It's [price] for the team, which works out at [price per person] each. [Mention a bulk discount if it applies.]
Questions managers usually ask
Can we pay by invoice? Yes. Every purchase comes with an invoice, and you can add your company's tax ID at checkout. To pay by bank transfer, email hello@helloworld.guide with your company name, billing address and any purchase order number, and we'll send one.
Is there a team licence? Yes. Team licences cover 2 to 500 people, with 25% off at 3 seats or more and 50% off at 10 seats or more. For larger teams, email hello@helloworld.guide. Everyone on the team gets their own login, and the seats belong to the company, so you can give someone's seat to someone else when they leave.
What if it isn't useful? If it isn't for you, email hello@helloworld.guide within 30 days for a full refund. No questions.
Can this go on the training budget? Usually, yes. It's a professional development course with a receipt or invoice, so it fits most training, learning or conference budgets. If your company reimburses you rather than paying directly, keep the receipt and file it the way you'd file a book or a conference ticket. Your finance team decides what counts, so check with them if you're unsure.
Does it only cover [our framework]?
No. The examples teach the standards underneath, like Unicode CLDR, ICU MessageFormat, BCP 47 language tags and the Intl APIs, which every mainstream platform builds on. Code examples come in more than one language, mostly JavaScript and PHP, and the ideas apply to any stack.
How long does it take? It's a book of 27 chapters, which you can read on the web or as a PDF. Most people work through the parts that matter for their next project first, then come back to the rest. Each topic stands on its own, so you don't have to finish it all before it's useful.
Do we get updates? Yes. The book is a living web reference that's updated as standards and tools change, and buyers get every update for life. The changelog lists what's changed.
Is it worth it if we aren't localising yet? Often, yes. Localising a large existing app is a lot of work, because every hard-coded string, date and price has to be found and changed. Putting the basics in place while the app is small costs very little by comparison. The book's playbook has a short "starting from scratch" list for exactly this.