Free tools Windows power users keep installed
One-click scans. No signup required.
Mubeen Khan says he added Spanish to UtilityHub—a site he describes as 12 free finance calculators and money guides—using Next.js 15, middleware, and static generation on Vercel. His reported design keeps English pages at their existing unprefixed URLs, puts Spanish pages under /es/ with translated slugs, and shares calculator logic across both languages. This is a first-person implementation account, not an independent audit of the live site, its search performance, or its build output.
The routing plan: keep English clean and put Spanish under /es/
Khan describes a single app/[locale] route segment with middleware deciding how each public path should resolve. In his setup, English remains the default locale without a URL prefix, while Spanish pages use /es/ and translated slugs. For example, the Spanish mortgage calculator is at /es/tools/calculadora-de-hipoteca.
/es/*serves Spanish content./en/*redirects with HTTP 308 to the equivalent unprefixed English URL.- Other paths are internally rewritten to
/en/*, leaving the public English URL unprefixed.
This arrangement is intended to preserve clean English URLs while making Spanish pages explicit. Khan characterizes the approach as having “zero SEO risk,” but the account does not supply indexing evidence or a before-and-after search comparison to demonstrate that outcome.
How translated slugs stay connected
Localized slugs need a reliable way to connect equivalent pages. Khan says he uses lib/slug-map.js to map English and Spanish slugs in both directions. Each page also reportedly emits reciprocal en, es, and x-default language alternates. Together, the slug map and alternates let the implementation identify the corresponding page in each language rather than assuming that translated pages share a URL structure.
#1 Best Overall
For an existing site, this is a consequential design choice: the English URL can remain stable, but every translated page needs a correct counterpart mapping. An incorrect or missing mapping could point visitors or crawlers to the wrong language version; the source describes Khan’s approach but does not include an independent validation of those mappings.
Keep translated content separate from calculator math
Khan says Spanish labels, explainers, FAQs, and metadata live in lib/tools.es.js, following the schema used by the English lib/tools.js. The calculation functions remain in the shared lib/calculations.js. As Khan puts it, “The math (lib/calculations.js) is shared — translation never touches numbers.”
Rank #2
The separation is useful for a calculator site because localized presentation and numeric behavior have different jobs. Translators can adapt wording and metadata without creating a second calculation implementation that might drift from the English version. That design alone does not prove two interfaces behave identically; Khan also reports a validation check for numeric defaults.
Validate the locale data before building
Khan reports writing a Node schema-validation script covering 12 entries. It checks three things:
Recommended Free Tools
- Field parity between the English and Spanish data structures.
- Four FAQs per entry.
- Numeric defaults that are byte-identical between locales.
These are checks the author says he implemented, not a test suite reviewed independently. The reported FAQ count is a project-specific schema rule, not a general requirement for bilingual sites. The broader lesson is to make locale parity explicit: decide which fields must exist in every language, which numeric values must remain unchanged, and what intentional differences—such as translated slugs—are allowed.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What Khan reports shipping
Khan says one build produced 59 static pages, with the document’s <html lang> set for the relevant locale and Spanish URLs included in the sitemap. These are reported outputs from his project; the account does not provide an independent crawl, indexing data, performance benchmark, traffic figures, or conversion results. The page count is therefore evidence of what Khan says the build generated, not a benchmark for what another Next.js localization project should produce.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
