English-only product shell
Adding locales later often forces route, metadata, and navigation rewrites.
Feature / i18n
Internationalization that helps both product rollout and multilingual SEO
BunShip includes locale-aware routing and bilingual content foundations so teams can launch in multiple languages without rebuilding the site map, docs center, and core product shells later.
- Locale-aware app router structure
- Marketing and docs localization path
- Supports multilingual SEO expansion
- Works across marketing, app, and docs surfaces
2
Live locales
English and Chinese are already present across the product surface.
3
Localized surfaces
Marketing pages, docs pages, and core product flows share one locale model.
SEO-ready
Routing model
Localized URLs and metadata infrastructure are already part of the app.
Internationalization is visible in the product shell, not hidden in a future roadmap note.
Locale routesLocalized docsShared navigationSearch-ready structure
What this page solves
Multilingual products fail when localization gets deferred until after launch and SEO structure has already fragmented.
Docs and marketing drift apart
If docs and marketing do not share the same locale model, international expansion becomes harder to maintain.
SEO intent gets scattered
Teams often create too many thin i18n pages instead of one clear multilingual feature page and focused docs.
What's included
This page should stay focused on the multilingual product foundation rather than fragmenting into thin SEO subpages.
Locale-aware routing
Marketing, docs, and product pages are already organized under a consistent locale path strategy.
Localized docs support
The docs center already handles multilingual documentation content.
Metadata foundation
Localized metadata and alternate paths are part of the SEO implementation, not an afterthought.
Why it matters
For indie hackers, startups, and agencies, i18n is usually a distribution and conversion multiplier rather than a purely technical feature.
Supports international acquisition
Localized routes and content foundations make expansion more credible and easier to execute.
Improves content reuse
The same product architecture can support marketing, docs, and future blog growth across locales.
Avoids i18n retrofits
Teams do not need to rebuild route structure after the product already has traffic.
Implementation notes
Use docs and deployment pages for the deeper technical and operational questions.
i18n docs
Review how routing, translation files, and docs localization are wired.
/docs/features/i18n
Deployment architecture
See how localization interacts with production metadata, routing, and publishing.
/stacks/deployment
Blog
Use blog posts later for long-tail multilingual SEO questions without fragmenting feature intent.
/blog
Who it's for
Useful for teams selling globally or serving clients in more than one language from the start.
Indie makers going global
Start with a bilingual product shell instead of postponing international reach until later.
Agencies building regional products
Reuse a route and metadata model that already accounts for multilingual delivery.
SaaS teams with docs-heavy onboarding
Keep product and documentation localization aligned as the product grows.
FAQ
This page should answer the product-level i18n questions while tutorials and long tails live elsewhere.
Next step
Use i18n as a growth and trust signal, not only a future engineering task
Read the implementation docs or continue evaluating BunShip through pricing and architecture pages.