diff --git a/packages/twenty-website/src/app/[locale]/(site)/layout.tsx b/packages/twenty-website/src/app/[locale]/(site)/layout.tsx index fb66a742d8..1304936f3c 100644 --- a/packages/twenty-website/src/app/[locale]/(site)/layout.tsx +++ b/packages/twenty-website/src/app/[locale]/(site)/layout.tsx @@ -4,18 +4,9 @@ import { getRouteI18n, type LocaleRouteParams, } from '@/platform/i18n/get-route-i18n'; +import { MenuStyleProvider } from '@/platform/menu-style'; import { Footer } from '@/sections/footer'; -// The site-chrome layout. Marketing pages live under (site) and get the shared -// footer here; focused pages (the application form) live in (focused) with no -// chrome. The footer is config-less shared chrome, so it belongs in a layout — -// the route structure decides who shows it, not a runtime visibility gate. The -// Menu stays per-page because its scheme varies per page (and product's is -// scroll-synced), so it can't be hoisted here without a flash. -// -// The footer reads i18n (getServerI18n), so this layout establishes the -// request-scoped i18n context the same way every [locale] route segment does: -// the segment that renders i18n content owns its getRouteI18n call. const SiteLayout = async ({ children, params, @@ -26,10 +17,10 @@ const SiteLayout = async ({ await getRouteI18n(params); return ( - <> + {children}