Blue Science: Four-language catalog for an LED maker
Client: Blue Science Year: 2024 Services: Web Design & Development, Four-language Content Architecture, Catalog UX Duration: Roughly 10-12 weeks Tech: WordPress, Elementor, WPML
The problem
Blue Science makes LED lighting for tunnels, streets, and industrial applications. Their buyers are municipal-infrastructure contractors, tunnel engineers, and plant managers in Korea, China, Japan, and English-speaking export markets. A typical product inquiry starts with a specification sheet: the buyer has a wattage range, a beam angle, a tunnel-class fixture requirement, and they want to see which Blue Science SKU meets it.
The old site was a flat product list. Every fixture lived as a standalone page and the only way to find a tunnel light was to already know you were looking at the tunnel-light category. Buyers who knew Blue Science by reputation could navigate it. Buyers who arrived by search engine could not.
Four-language delivery (EN, KO, zh-Hans, JA) was the second hard requirement. Three of those four languages use different character sets and break different things in a default WordPress theme. The site needed to render correctly in all four without a separate build per language.
What we built
A four-language LED catalog with category-filtered discovery, project-portfolio evidence, and a searchable knowledge base.
- Category navigation: LED Tunnel Light Fixtures, LED Street Light Fixtures, industrial lighting applications
- Product filter with nested menu structure (category > type > wattage > application)
- Site-wide search that indexes product spec data alongside descriptive content
- Project portfolio page showing installed projects with photography
- Technology knowledge base with articles on thermally conductive composites and temperature-compensation circuits (the actual R&D Blue Science does on the hardware side)
- Four-language delivery via WPML: English, Korean, Simplified Chinese, Japanese
- Product-inquiry form routed to the right regional sales contact by visitor origin
- Application-vertical landing pages cross-linked with the product tree
How we built it
Weeks 1-2. Product data extraction. Blue Science had over a hundred SKUs and the spec data was spread across PDFs, internal spreadsheets, and legacy CMS pages. We consolidated everything into a single master sheet before touching the new site.
Weeks 3-4. Category tree design. The filter has to work for three different buyer mental models: someone shopping by fixture type, someone shopping by application vertical, someone shopping by technical spec. We designed the nested filter to cover all three without three separate UIs.
Weeks 5-6. Elementor build with custom product post type. Product pages carry their spec data as structured fields rather than body copy, so the filter can query them cleanly.
Weeks 7-8. Project portfolio and knowledge base build. Photography and tech-article content gathered and laid out.
Weeks 9-10. WPML setup for four languages. Korean first (primary), then English, then Simplified Chinese, then Japanese. Each language pass needed a native reviewer. Character-set layout testing found three places where long Chinese product names broke the filter UI; fixed before launch.
Weeks 11-12. Search indexing, final QA across locales, launch.
What it changed
Buyers who land on the site from a language that isn't English now reach a product page in two or three clicks instead of bouncing. That sounds obvious and was the hard part: in the old site, the Japanese landing page existed but the Japanese product search did not work properly against product names stored only in Korean.
What we learned
Four-language is where character-set bugs live. Korean and English co-exist peacefully in most layouts. Add Japanese and Simplified Chinese and you suddenly have three different scripts sharing a UI grid. Long strings in one language break the width of a filter chip in another. Test every multilingual UI element in its worst-case-length version in every language.
Product filters need structured data underneath. Early Blue Science drafts tried to filter by parsing body copy. It did not work. The filter became useful only after we restructured every product into typed fields: wattage range, IP rating, beam angle, application vertical, fixture-class certification. Treat product pages as data, not content.
Project-portfolio photography beats capability copy. Blue Science has hundreds of projects installed. Seeing the tunnel light inside the actual tunnel did more sales work than the spec sheet did. Buyers in this vertical trust the photo before they read the fixture class.
Stack
- WordPress
- Elementor
- WPML for EN/KO/zh-Hans/JA delivery
- Custom product post type with typed spec fields
- Filter + search with structured-data indexing
- Project portfolio module with category cross-linking
Want something similar?
Large multilingual product catalogs where the filter UX is the buyer's primary discovery tool. LED, lighting, fixtures, industrial components, specialty hardware in three or four languages. Email hello@cclemang.com or see web design and development.
