# Does OpenSEO Support Multiple Languages and Internationalization? > Discover if OpenSEO supports multiple languages and internationalization. Learn why its US English codebase lacks locale support and translation infrastructure. - Repository: [Every App/open-seo](https://github.com/every-app/open-seo) - Tags: faq - Published: 2026-06-28 --- **OpenSEO does not support multiple languages or internationalization; the codebase is hard-coded for US English with no locale selector or translation infrastructure.** OpenSEO is an open-source SEO platform engineered with a single-locale architecture. While modern web applications typically implement internationalization (i18n) frameworks to serve global audiences, the OpenSEO repository contains no translation files, locale-specific resources, or multi-language UI components. According to the source code in `every-app/open-seo`, the entire application assumes a United States/English locale with explicit hard-coding that prevents extensibility for other languages or regions. ## Hard-Coded Locale in AI-Search Services The only evidence of locale handling in OpenSEO exists within the **share-of-voice** service for the AI-search feature. In [`src/server/features/ai-search/services/shareOfVoice.ts`](https://github.com/every-app/open-seo/blob/main/src/server/features/ai-search/services/shareOfVoice.ts), a developer comment explicitly documents the application's restrictive language support: ```ts // src/server/features/ai-search/services/shareOfVoice.ts // US/en assumption: today the only locale that exists for both platforms is // US/en (the UI hardcodes locationCode 2840 / languageCode en and has no locale selector) ``` This comment reveals that **OpenSEO hardcodes `locationCode 2840`** (United States) and **`languageCode en`** (English) directly in the service logic. The implementation assumes these are the only supported values and explicitly acknowledges the absence of a locale selector in the user interface. ## Absence of Internationalization Infrastructure A comprehensive review of the repository confirms no internationalization infrastructure exists. Unlike standard i18n implementations that utilize libraries such as `react-intl`, `formatjs`, or `i18next`, OpenSEO contains none of these dependencies. Searches for i18n-related keywords yield only generic string utilities rather than localization logic. For example, [`web/src/lib/content.functions.ts`](https://github.com/every-app/open-seo/blob/main/web/src/lib/content.functions.ts) uses `localeCompare` for basic string sorting, but this represents standard JavaScript functionality rather than multi-language support. Key indicators of the single-language architecture include: - **No translation files** or `.json` resource bundles for alternative languages - **No locale configuration** mentioned in [`README.md`](https://github.com/every-app/open-seo/blob/main/README.md) or environment schemas - **No i18n imports** across the TypeScript and React codebase - **Hard-coded English strings** throughout the UI layer without abstraction for translation keys ## Implications for Multi-Language Support Attempting to add a new locale to OpenSEO would require significant architectural modifications. Developers would need to: 1. Replace hard-coded `locationCode` and `languageCode` values with dynamic configuration parameters 2. Implement a locale selector in the frontend to replace the current hardcoded UI assumptions 3. Integrate a translation management system with resource files for each target language 4. Refactor services like the share-of-voice calculator to handle multiple regional data sources correctly ## Summary - OpenSEO is built exclusively for **US English** with hard-coded locale assumptions that limit global usability - The file [`src/server/features/ai-search/services/shareOfVoice.ts`](https://github.com/every-app/open-seo/blob/main/src/server/features/ai-search/services/shareOfVoice.ts) explicitly documents the `locationCode 2840` / `languageCode en` constraint - **No i18n libraries** (react-intl, i18next, formatjs) are present in the dependency tree or source code - The application lacks translation files, locale selectors, or configurable language settings in [`README.md`](https://github.com/every-app/open-seo/blob/main/README.md) - Adding internationalization support requires fundamental refactoring of service architecture and UI components ## Frequently Asked Questions ### Does OpenSEO support non-English languages? No. The codebase contains no translation infrastructure, and the AI-search services explicitly assume US English locale settings. All user-facing content is rendered in English without abstraction layers for localization or regional formatting. ### Can I configure the locale in OpenSEO? No. There is no locale selector in the UI, and regional parameters are hard-coded in the source. Specifically, [`src/server/features/ai-search/services/shareOfVoice.ts`](https://github.com/every-app/open-seo/blob/main/src/server/features/ai-search/services/shareOfVoice.ts) uses fixed values for `locationCode 2840` (United States) and `languageCode en` (English) with no environment variables or configuration mechanism to override these defaults. ### What i18n libraries does OpenSEO use? None. The repository does not implement `react-intl`, `formatjs`, `i18next`, or any similar internationalization frameworks. The only locale-related code found is generic string comparison using `localeCompare` in utility files such as [`web/src/lib/content.functions.ts`](https://github.com/every-app/open-seo/blob/main/web/src/lib/content.functions.ts), which does not constitute internationalization support. ### How would I add multi-language support to OpenSEO? You would need to refactor the hard-coded locale values in [`shareOfVoice.ts`](https://github.com/every-app/open-seo/blob/main/shareOfVoice.ts) into configurable properties, add a locale selector component to the React frontend, and implement a translation layer with resource files for each supported language. The current architecture assumes a single locale, so supporting multiple languages requires structural changes to data services and UI components.