feat: support automatic i18n detection for ConfigProvider

[Col0ring]

No description provided.

[changeset-bot]

🦋 Changeset detected

Latest commit: 4093b01

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[gemini-code-assist]

Summary of Changes

Hello @Col0ring, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant enhancement to the application's internationalization capabilities by enabling automatic locale detection for the ConfigProvider. This change streamlines the process of displaying content in the user's native language, improving usability and reducing the need for explicit language settings. Additionally, it includes foundational changes in the backend component structure to support more flexible property handling.

Highlights

• Automatic Internationalization (i18n) Detection: The ConfigProvider component now automatically detects the user's preferred language from the browser's navigator settings. This enhances user experience by providing localized content without manual configuration.
• Robust Locale Handling: The system now includes a formatLocale utility to standardize locale strings and gracefully falls back to en_US if the detected locale is not explicitly supported, ensuring a consistent user interface.
• Backend Component Flexibility: The __init__ methods for core backend components (Component, Block, Context) have been updated to accept and pass arbitrary keyword arguments (**kwargs) to their superclass constructors. This provides greater flexibility for future component extensions and property passing.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces automatic i18n detection for the ConfigProvider, which is a great feature. The backend changes in Python are solid improvements for component extensibility. In the frontend, the logic to detect the browser's locale is a good start, but I've found a significant issue in how the locale string is processed. The current implementation doesn't handle all common locale formats, which could lead to incorrect language display for many users. I've provided a detailed comment with a suggested fix to make the locale detection more robust.

[gemini-code-assist]

The formatLocale function is not robust enough. It only handles locales with exactly two parts (like en-US), but getLocaleFromNavigator() can return single-part locales (e.g., en, fr) or multi-part locales (e.g., zh-Hans-CN). In these cases, your function will incorrectly fall back to en_US, defeating the purpose of automatic locale detection for many users.

For example, if the browser's language is French (fr), this function will return en_US instead of a French locale like fr_FR.

function formatLocale(locale: string | null) {
  if (!locale) {
    return 'en_US';
  }

  const parts = locale.replace('-', '_').split('_');
  const lang = parts[0].toLowerCase();

  // Try to match specific region first (e.g., en_GB, or zh_CN from zh_Hans_CN)
  if (parts.length >= 2) {
    const region = parts[parts.length - 1].toUpperCase();
    const formattedLocale = `${lang}_${region}`;
    if (locales[formattedLocale]) {
      return formattedLocale;
    }
  }

  // Fallback to first available locale for the language
  if (lang === 'zh') {
    return 'zh_CN';
  }
  const matchingLocale = Object.keys(locales).find((key) =>
    key.startsWith(`${lang}_`)
  );
  return matchingLocale || 'en_US';
}