r/RacterMX

This one surprised people when we shipped it. An email forwarding service with full internationalization isn't something you see often. Most providers are English-only, maybe with a Spanish or French translation that covers half the UI and falls back to English for the rest.

We went all in.

10 languages

English, Spanish, French, German, Italian, Hindi, Japanese, Portuguese (Brazilian), Chinese (Simplified), and Arabic.

Every surface is translated:

• All marketing pages (home, pricing, about, comparisons, blog index, changelog)
• The full dashboard (domain tree, tabs, settings, command palette, status messages)
• Email templates (verification, password reset, notifications, scheduled reports)
• Error messages and validation feedback
• The onboarding wizard
• The TOS acceptance screen
• The billing page

We're talking about 2,300+ translation keys per locale. Not a partial effort where the landing page is translated but the dashboard reverts to English the moment you log in.

Arabic and RTL

Arabic was the hardest to get right. It's not just translating strings. The entire layout needs to flip: navigation goes right-to-left, text alignment reverses, directional icons mirror, and CSS needs to account for the different reading direction.

We added dir="rtl" detection based on the active locale and wrote RTL-specific CSS overrides for the navigation, footer, sidebar, dropdowns, and form layouts. The marketing pages and the dashboard both respect the direction.

How it works technically

We use Laravel's __() translation function with JSON locale files. Each locale has a single JSON file mapping English keys to translated values. The SetLocale middleware reads the user's preference from their session cookie (set via the language switcher) or falls back to the Accept-Language header.

Marketing pages have locale-prefixed URLs for SEO: /es/pricing, /fr/about, /de/pricing, etc. Each localized URL gets proper hreflang tags and an x-default pointing to the English version. Canonical tags on localized pages point to the English URL to avoid duplicate content issues with search engines.

The language switcher

It's in the navigation bar on every page. Shows the current locale code (EN, ES, FR, etc.) with a globe icon. Click it, pick your language, the page reloads in that locale. Your preference is saved in a cookie so it persists across sessions.

What we learned

Some things that caught us off guard:

• Date formatting varies wildly. "April 19, 2026" in English becomes "19 avril 2026" in French and "2026年4月19日" in Japanese. Laravel's translatedFormat() handles this but you have to use it consistently everywhere.
• Number formatting matters too. "1,000.50" in English is "1.000,50" in German. Currency symbols go in different positions.
• Some translated strings are significantly longer than English, which breaks layouts that were designed for English string lengths. German is especially bad for this.
• RTL isn't just "flip everything." Some elements (like code blocks, URLs, and email addresses) should stay left-to-right even in an RTL context.

Why bother?

Email is global. If someone in Tokyo or Riyadh or Sao Paulo wants to manage their domain's email forwarding, they shouldn't have to do it in a language they're not comfortable with. The infrastructure doesn't care what language the UI is in, so there's no technical reason to limit it.

What languages are underserved in the email infrastructure space? Are there locales we should add? We're open to expanding if there's demand.

DNS changes are high-stakes and low-visibility. You update a record, propagation takes anywhere from minutes to hours, and if something breaks you're scrambling to remember what the old value was. Most DNS providers give you a zone editor and nothing else. No history, no undo, no way to see what changed and when.

We built versioned zone history into our DNS hosting because we kept running into this ourselves.

How it works

Every time a record is created, modified, or deleted in your zone, we take a snapshot. The snapshot captures the full zone state at that point in time. You can browse the history, see exactly what changed between any two snapshots, and roll back to a previous state with one click.

The diff view

Pick any two snapshots and we show you a side-by-side diff. Added records are highlighted in green, removed records in red, modified records show the old and new values. It looks like a git diff but for DNS records.

This is useful for debugging. "Mail stopped working yesterday afternoon." Open the zone history, look at what changed yesterday, and there's your answer. Maybe someone deleted an MX record. Maybe the SPF record got modified and now it's too long. Maybe a CNAME was added that conflicts with an existing record.

One-click rollback

Found the problem? Click rollback on the snapshot you want to restore. We rewrite the zone to match that snapshot's state. The rollback itself creates a new snapshot, so you can always undo the undo.

Drift detection

This one catches a subtle problem. If someone modifies your DNS records outside of our editor (at the registrar, through a different API, or via a script that talks to PowerDNS directly), the zone state drifts from what our history shows. We detect this drift and alert you.

Drift detection matters because unauthorized DNS changes can indicate compromise. If your MX records suddenly point somewhere else and nobody on your team made the change, that's a serious problem. The alert gives you a chance to investigate and roll back before damage is done.

You can acknowledge a drift event if the change was intentional (maybe you ran a migration script), which updates the baseline snapshot so it stops alerting.

What gets versioned

Every record type: A, AAAA, CNAME, MX, TXT, SRV, NS, CAA, and anything else in the zone. The snapshot includes the full record set with names, types, values, TTLs, and priorities.

Via API

Zone history is accessible through the REST API. You can query snapshots, view diffs, and trigger rollbacks programmatically. Useful if you're building deployment pipelines that include DNS changes and want automated rollback on failure.

How do you track DNS changes today? We've talked to people who use everything from "I keep a spreadsheet" to "we version our zone files in git" to "we don't track changes at all and just hope for the best." Curious where people land on this.