[Bug] report: DeepSeek UI served in Arabic when browser locale is es-AR / es_AR

[emezeta]

Summary

When a user has the es-AR (Spanish-Argentina) locale set as their primary browser language, the DeepSeek web interface is served in Arabic instead of Spanish. The issue is reproducible and disappears when the locale is changed to generic es or to es-ES.

Affected environment

• Browser: Chromium 149.0.7827.155 (Official Build) on Debian GNU/Linux forky/sid (64-bit)
• Language configuration: Spanish (Argentina) as the only or primary locale for language/dictionary
• System: No Arabic language packs installed, no Arabic dictionary, no Accept-Language headers containing ar
• Other websites: Render correctly in Spanish; only DeepSeek shows the UI in Arabic

Steps to reproduce

1. In Chromium (or any Chromium-based browser), set the language/dictionary to Spanish (Argentina) (es-AR or es_AR).
2. Ensure no Arabic language is configured or installed.
3. Navigate to chat.deepseek.com.
4. Observe that the UI is served in Arabic.

Expected behavior

The UI should be served in Spanish, since the browser locale is es-AR. Proper language negotiation (RFC 4647 lookup) should resolve es-AR → es (Spanish) and serve the UI in Spanish.

Observed behavior

The UI is served in Arabic.

Root cause analysis (hypothesis)

The ISO 639-1 language code for Arabic is ar. The Spanish-Argentina locale is written es-AR (BCP 47) or es_AR (POSIX). There are several ways a buggy parser can produce the collision:

• Extracting the region segment as if it were the base language: if the code does locale.split('-')[1] or split('_')[1], takes AR, and lowercases it (ar), the result is the Arabic code.
• Substring matching without normalization: an includes('ar') or a /ar/i regex against the string es-AR matches Arabic.
• Inconsistent handling of hyphen vs. underscore: es-AR vs es_AR. If only one of the two formats is handled and the other falls into a fallback whose default value is ar (e.g., because Arabic is the first language in the supported-locales table), the UI is served in Arabic.

Suggested checks for the development team

1. Use a real BCP 47 parser (Intl.Locale in JS) instead of manual string splits.
2. Implement RFC 4647 lookup: for es-AR, try es-AR → es → default language. Never jump to another base language.
3. Add explicit unit tests: resolveLocale('es_AR'), resolveLocale('es-AR'), resolveLocale('es_AR.UTF-8') must all return es, not ar.
4. Check whether ar appears before es in the supported-locales table, and whether any find() returns the first substring match.
5. Check the client side as well: if navigator.language is read and any loose regex is applied, es-AR matches ar.

Additional context: why this affects more people than it seems

The es-AR locale is not used only by users in Argentina. Uruguayans who choose es-AR because of the Rioplatense Spanish shared across the Río de la Plata, Paraguayans due to proximity, and anyone working with Argentine content are also affected. The collision does not respect borders.

Evidence that the problem is on DeepSeek's server/client side

• The browser has no Arabic language component installed.
• Other websites are served correctly in Spanish.
• Changing es-AR to es (or es-ES) resolves the problem immediately.
• There is no Accept-Language: ar anywhere in the browser configuration.

---