We built Custom Sign Forge as a B2B website for custom commercial signage. The public site has ten language versions and six product families. The implementation uses Astro and React on Cloudflare Workers, with D1 for application data and private R2 storage for uploads.
The interesting part was not adding a language switcher. It was keeping the product pages, imagery, enquiry flow, and search metadata coherent as the site grew. Here are the lessons that would carry into another multilingual build.
1. Keep locale routing explicit
English uses the original URLs; other languages have prefixes such as /zh/, /pt-br/, and /ar/. We do not redirect visitors based on IP address or browser language. A visitor can choose a language and share a stable URL.
One routing module owns the conversion between equivalent pages. Product slugs and internal field codes remain stable. A language change updates the visible text and labels, but it does not rewrite customer-entered text or change the underlying enquiry record. This separation matters when a customer starts an enquiry in one language and returns in another.
2. Translation coverage is a UI problem, too
A dictionary can be complete while the interface is not. We found untranslated navigation text in the Arabic account menu. We also caught a wrong flag next to a language label. Neither would be found by a simple check that counts translated strings.
We now treat the header, account menu, validation messages, upload controls, policy links, and enquiry summary as part of every locale's acceptance criteria. For Arabic, the check also includes RTL layout, icon direction, mixed Latin/Arabic text, and alignment. We keep the actual language name visible because a flag alone is a poor identifier for a language used in multiple countries.
Arabic homepage screenshot: the navigation and hero follow a right-to-left layout. The storefront scene is a labelled design concept.
3. Image composition needs its own content model
Our first Chinese product layouts exposed a familiar problem: applying the same fixed image box and object-fit: cover rule to every asset. Some signage photos are wide; others are close-ups or portrait compositions. A uniform crop can remove the sign itself. Switching every image to contain is not enough either; it may create awkward empty bands.
We changed the gallery approach instead. Each image gets a frame appropriate to its purpose and source aspect ratio. Product design concepts use consistent 4:3 compositions; wide construction photographs keep their native proportions. On mobile, the grid becomes a single column, and the enquiry action stays easy to reach before a long image sequence. We also label generated design concepts as concepts rather than implying that they are photographs of completed customer projects.
Chinese product-page screenshot: equal landscape frames make the design concepts comparable without cropping away the signs. These are design inspirations, not completed customer installations.
The reusable rule: decide whether an image is a hero, a comparison, a detail, or evidence before choosing its crop behavior. Inspect the actual focal point at desktop and phone widths.
4. Search metadata is part of localization
Each public locale page renders its own HTML language, title, description, H1, and canonical URL. Equivalent pages carry reciprocal hreflang links, and the sitemap includes locale alternates. Private account and admin paths are kept out of the public index. This prevents the common failure where a translated page looks localized but still advertises the English canonical URL.
A sitemap submission is only a discovery signal, not a guarantee of indexing. We still check the live HTML, response status, robots rules, and Search Console reports after deployment.
5. Share the business flow; localize its presentation
The quote form uses shared sessions, CSRF protection, stable field codes, and private attachments across languages. The submitted locale is stored with the enquiry, while the original customer wording remains untouched. A language-only retry reuses the existing idempotency key so it does not create a duplicate enquiry.
This gave us one set of business rules to test, with a separate presentation layer for each language. It also exposed the places that need real browser testing: sign-in return paths, draft restoration, optional uploads, validation, and account summaries.
6. Test the rendered pages, not just the translation files
For each new locale, our release checklist now combines automated checks with a small visual matrix: homepage, product index, all six product detail pages, account menu, quote flow, and mobile header. We inspect long headings, contrast, missing images, focal-point crops, and language leaks. Arabic adds RTL-specific checks.
The broader lesson is that internationalization is a product quality discipline. A locale is ready when its content, layout, interaction, and search signals work together—not when the JSON file is filled.
Disclosure: This article was generated by an AI agent from the project's source and implementation notes. Factual implementation details were checked against those materials. It is a technical case study, not a claim that AI-generated concept images are completed customer installations.
Top comments (0)