# State Management Standards for Internationalization

This document outlines the coding standards for managing state in applications with Internationalization (i18n) in mind. It guides developers to adopt best practices for handling localized data, including text, numbers, dates, currencies, and other culturally sensitive information. This document helps improve the maintainability, scalability, and performance of i18n-aware applications.

## 1. Introduction to i18n State Management

Effective state management is crucial for applications with i18n requirements. It involves organizing, storing, and updating localized data, ensuring that the UI reflects the correct language and cultural conventions. Modern applications increasingly rely on reactive state management solutions to efficiently update the UI when locale or content changes.

### 1.1 Importance of Centralized State

Centralizing i18n-related state offers several advantages:

* **Consistency**: Ensures a consistent i18n experience across the application.

* **Maintainability**: Simplifies updating or modifying i18n data, improving code maintainability.

* **Performance**: Facilitates efficient data caching and retrieval, optimizing performance.

### 1.2 Types of i18n State

i18n state typically includes:

* **Current Locale**: The active locale selected by the user (e.g., "en-US", "fr-CA").

* **Translation Messages**: A dictionary of translated strings for different locales.

* **Number and Date Formats**: Locale-specific formatting rules.

* **Currency Information**: Symbols, positions, and decimal separators.

## 2. Core Principles for Managing i18n State

### 2.1 Single Source of Truth

**Principle**: Maintain a single, authoritative source for all i18n-related data.

**Why**: Prevents inconsistencies and simplifies state updates.

**Do This**: Use a centralized state management solution (e.g., Redux, Vuex, Zustand, React Context) to store i18n data.

**Don't Do This**: Avoid scattering i18n data across components or modules.

**Example (React with Context):**

"""jsx

// I18nContext.js

import React, { createContext, useState, useEffect, useContext } from 'react';

import en from './translations/en.json';

import fr from './translations/fr.json';

const I18nContext = createContext();

const translations = {

en: en,

fr: fr,

};

export const I18nProvider = ({ children }) => {

const [locale, setLocale] = useState(localStorage.getItem('locale') || 'en'); // Load from localStorage or default to 'en'

const [messages, setMessages] = useState(translations[locale]);

useEffect(() => {

localStorage.setItem('locale', locale); // Store locale in localStorage

setMessages(translations[locale]); // Update messages when locale changes

}, [locale]);

const t = (key) => {

return messages[key] || key; // Fallback to the key if translation is missing

};

const value = {

locale,

setLocale,

};

return (

{children}

);

};

export const useI18n = () => useContext(I18nContext);

// App.js

import React from 'react';

import { I18nProvider, useI18n } from './I18nContext';

const Home = () => {

const { t, locale, setLocale } = useI18n();

return (

{t('greeting')}

{t('description')}

setLocale(locale === 'en' ? 'fr' : 'en')}>

{t('changeLocale')}

);

};

const App = () => {

return (

);

};

export default App;

"""

In this example:

* "I18nContext" stores the current locale and translation messages.

* "I18nProvider" provides these values to its children.

* "useI18n" is a custom hook for accessing the context.

* The locale is persisted in local storage.

* The "t" function handles translation lookups, using a key-based approach.

### 2.2 Immutability

**Principle**: Treat i18n state as immutable.

**Why**: Simplifies state change detection and improves debugging. Makes state predictable.

**Do This**: When updating i18n state, create a new state object instead of modifying the existing one.

**Don't Do This**: Directly modify the i18n state object.

**Example (React with useState):**

"""jsx

import React, { useState } from 'react';

function LocaleSwitcher() {

const [locale, setLocale] = useState('en-US');

const changeLocale = (newLocale) => {

// DO THIS: Create a new state object

setLocale(newLocale);

// DON'T DO THIS: Mutate the existing state

// locale = newLocale; // This is an anti-pattern in React

};

return (

Current Locale: {locale}

changeLocale('fr-CA')}>Switch to French (Canada)

changeLocale('de-DE')}>Switch to German (Germany)

);

}

"""

### 2.3 Reactivity

**Principle**: Ensure that UI components react automatically to changes in i18n state.

**Why**: Keeps the UI consistent with the current locale and data.

**Do This**: Use reactive state management solutions (e.g., React Context, Redux, Vuex, Zustand) to connect UI components to the i18n state.

**Don't Do This**: Manually update UI components when i18n data changes.

**Example (React with Context - continued from above):**

The "Home" component automatically re-renders when the "locale" state changes, thanks to the "useI18n" hook and the "I18nContext". No manual updates are needed.

### 2.4 Lazy Loading Translations

**Principle**: Load translation messages only when they are needed.

**Why**: Improves initial load time and reduces memory usage. Optimizes the loading of heavy translation files.

**Do This**: Use dynamic imports or code splitting to load translation files based on the current locale.

**Don't Do This**: Load all translation files at application startup.

**Example (Dynamic Imports in React):**

"""jsx

import React, { useState, useEffect, createContext, useContext } from 'react';

const I18nContext = createContext();

export const I18nProvider = ({ children }) => {

const [locale, setLocale] = useState(localStorage.getItem('locale') || 'en');

const [messages, setMessages] = useState({});

const [loading, setLoading] = useState(true);

useEffect(() => {

setLoading(true);

import("./translations/${locale}.json") // Dynamic import

.then((module) => {

setMessages(module.default);

setLoading(false);

})

.catch((error) => {

console.error("Failed to load translations:", error);

setMessages({}); // Set to empty object to avoid errors

setLoading(false);

});

localStorage.setItem('locale', locale);

}, [locale]);

const t = (key) => {

return messages[key] || key; // Fallback

};

const value = {

locale,

setLocale,

loading,

};

return (

{loading ? Loading... : children}

);

};

export const useI18n = () => useContext(I18nContext);

"""

In this example, the translation file for the current locale is loaded dynamically using "import()". A loading state ensures that components don't try to render before the translations are ready.

### 2.5 Locale Detection

**Principle**: Automatically detect the user's preferred locale.

**Why**: Provides a better user experience by presenting content in the user's language.

**Do This**:

* Use the "navigator.language" property in the browser.

* Check the "Accept-Language" header on the server side.

* Allow the user to override the detected locale.

* Persist the user's choice in local storage or cookies.

**Don't Do This**:

* Rely solely on IP address geolocation (inaccurate and privacy concerns.)

* Force users into a specific locale without providing an option to change it.

**Example (Detecting and Setting Locale):**

"""javascript

function detectLocale() {

// Check local storage first

const storedLocale = localStorage.getItem('locale');

if (storedLocale) {

return storedLocale;

}

// Detect browser language

const browserLocale = navigator.language || navigator.userLanguage; //userLanguage is for IE

if (browserLocale) {

return browserLocale; // This may need sanitization and validation

}

return 'en-US'; // Default locale

}

// Usage in the I18nProvider:

import React, { createContext, useState, useEffect, useContext } from 'react';

// ... (I18nContext definition)

export const I18nProvider = ({ children }) => {

const [locale, setLocale] = useState(detectLocale());

// rest of the provider

}

"""

This example first checks localStorage for a previously selected locale. If not found, it uses the browser's language settings. Error conditions should be handled, e.g., when an unsupported language is detected. The determined locale becomes the initial state.

### 2.6 Managing Fallbacks

**Principle**: Implement a fallback mechanism for missing translations.

**Why**: Ensures that the application remains functional even if some translations are not available for a specific locale.

**Do This**:

* Have a default locale (e.g., "en-US") that contains all translation keys and values.

* Implement a fallback chain (e.g., if "fr-CA" is missing a key, fall back to "fr", then to "en-US").

* Display a warning or error message in development mode when a translation is missing.

**Don't Do This**:

* Display untranslated keys to the user in production.

* Fail silently when a translation is missing.

**Example (Translation Fallback Function):**

"""javascript

const translations = {

'en-US': {

'greeting': 'Hello',

'description': 'Welcome to our website.',

'fr': {

'greeting': 'Bonjour'

}

};

function translate(key, locale) {

const localeTranslations = translations[locale];

if (localeTranslations && localeTranslations[key]) {

return localeTranslations[key];

}

const baseLocale = locale.split('-')[0]; // fallback to the language code

const baseLocaleTranslations = translations[baseLocale];

if (baseLocaleTranslations && baseLocaleTranslations[key]) {

return baseLocaleTranslations[key];

}

const defaultTranslations = translations['en-US']; // Fallback to en-US

if (defaultTranslations && defaultTranslations[key]) {

return defaultTranslations[key];

}

console.warn("Missing translation for key "${key}" in locale "${locale}"");

return key; // Return the key as a last resort

}

// Usage:

console.log(translate('greeting', 'fr-CA')); // Output: Bonjour

console.log(translate('description', 'fr-CA')); // Output: Welcome to our website.

console.log(translate('missingKey', 'fr-CA')); // Output: missingKey (and a warning in the console)

"""

This "translate" function implements a fallback chain: locale-specific, language-specific, and then the default "en-US" locale. It also logs a warning to the console for missing translations, which is helpful during development.

## 3. State Management Libraries and Frameworks

### 3.1 React Context API

**Description**: React's built-in context API allows you to share state between components without having to pass props manually at every level.

**Pros**:

* Simple and lightweight

* No external dependencies

* Easy to use for small to medium-sized applications

**Cons**:

* Not optimized for frequent updates in large applications (potential performance issues)

* Lacks advanced features like middleware and devtools

**Best Use Cases**: Managing locale and simple translation messages in smaller React applications.

**Example**: (See Section 2.1)

### 3.2 Redux

**Description**: A predictable state container for JavaScript apps.

**Pros**:

* Centralized state management

* Predictable state changes

* Middleware support for handling asynchronous actions

* DevTools for debugging

**Cons**:

* More complex setup and boilerplate code

* Can be overkill for small applications

**Best Use Cases**: Large, complex applications with many components and frequent state updates.

**Example (Redux with React):**

"""javascript

// i18nActions.js

export const SET_LOCALE = 'SET_LOCALE';

export const setLocale = (locale) => ({

type: SET_LOCALE,

payload: locale,

});

// i18nReducer.js

const initialState = {

locale: 'en-US',

messages: {},

};

const i18nReducer = (state = initialState, action) => {

switch (action.type) {

case SET_LOCALE:

return {

...state,

locale: action.payload,

};

default:

return state;

}

};

export default i18nReducer;

// store.js

import { configureStore } from '@reduxjs/toolkit';

import i18nReducer from './i18nReducer';

const store = configureStore({

reducer: {

i18n: i18nReducer,

});

export default store;

// App.js

import React, { useEffect } from 'react';

import { useDispatch, useSelector } from 'react-redux';

import { setLocale } from './i18nActions';

import { loadTranslations } from './translationService'; // Assume this function fetches translations

import { I18nextProvider } from 'react-i18next';

import i18n from './i18n'; // your i18next instance

function App() {

const dispatch = useDispatch();

const locale = useSelector((state) => state.i18n.locale);

useEffect(() => {

i18n.changeLanguage(locale); // set i18next language when locale changes

}, [locale]);

const changeLocale = (newLocale) => {

dispatch(setLocale(newLocale));

};

return (

Current Locale: {locale}

changeLocale('fr-CA')}>Switch to French (Canada)

changeLocale('de-DE')}>Switch to German (Germany)

);

}

export default App;

"""

This example demonstrates a basic Redux setup for i18n:

1. **Actions**: "setLocale" is an action creator to update the locale.

2. **Reducer**: "i18nReducer" handles the "SET_LOCALE" action. Note: In a real application, this reducer would probably also handle loading translation messages.

3. **Store**: Configures the Redux store with the "i18nReducer".

4. **Component**: "App" uses "useDispatch" and "useSelector" to interact with the Redux store and trigger locale changes. This component uses i18next to perform translation, based on the locale loaded into Redux.

### 3.3 Zustand

**Description**: A small, fast and scalable bearbones state-management solution using simplified flux principles. It is unopinionated and doesn't wrap your components in providers.

**Pros**:

* Minimal boilerplate

* Easy to learn

* Good performance

**Cons**:

* Less mature ecosystem compared to Redux.

* Fewer advanced features (middleware, devtools).

**Best Use Cases**: Medium-sized applications where simplicity and performance are crucial.

**Example (Zustand):**

"""javascript

import create from 'zustand';

const useI18nStore = create((set) => ({

locale: 'en-US',

messages: {},

setLocale: (newLocale) => set({ locale: newLocale }),

setMessages: (newMessages) => set({ messages: newMessages }),

}));

// Usage

import React, { useEffect } from 'react';

import useI18nStore from './i18nStore';

import { loadTranslations } from './translationService'; // Assume this function fetches translations

import { I18nextProvider } from 'react-i18next';

import i18n from './i18n'; // your i18next instance

function App() {

const { locale, setLocale } = useI18nStore();

useEffect(() => {

i18n.changeLanguage(locale); // set i18next language when locale changes

}, [locale]);

const changeLocale = (newLocale) => {

setLocale(newLocale);

};

return (

Current Locale: {locale}

changeLocale('fr-CA')}>Switch to French (Canada)

changeLocale('de-DE')}>Switch to German (Germany)

);

}

export default App;

"""

This example demonstrates a basic Zustand setup for i18n. The "useI18nStore" hook provides access to the "locale", "messages", "setLocale", and "setMessages" state and actions. The component renders translated text using i18next. Note the minimal boilerplate required, making Zustand a lean alternative to Redux in many situations.

### 3.4 Choosing a Solution

Here's a table summarizing factors to consider:

| ---------------- | ------------- | -------- | --------- |

| Boilerplate | Low | High | Low |

## 4. Data Fetching and Caching

### 4.1 Fetching Translations

**Standard**: Asynchronously fetch translation files from a server or local storage when the locale changes.

**Why**: Improves performance by loading only the necessary translations.

**Do This**: Use "fetch" or "axios" to load JSON files containing translations. Cache the fetched translations to avoid redundant requests.

**Don't Do This**: Include all translations in the initial bundle.

**Example (Fetching Translations):**

"""javascript

async function loadTranslations(locale) {

try {

const response = await fetch("/locales/${locale}.json");

if (!response.ok) {

throw new Error("HTTP error! status: ${response.status}");

}

const data = await response.json();

return data;

} catch (error) {

console.error('Failed to load translations:', error);

return {};

}

// Usage in a React component:

import React, { useState, useEffect } from 'react';

function MyComponent({ locale }) {

const [translations, setTranslations] = useState({});

useEffect(() => {

loadTranslations(locale).then(data => setTranslations(data));

}, [locale]);

return (

{/* Use translations here */}

);

}

"""

This example fetches the translation file for the specified locale. It also include error handling and returns empty object on errors, preventing the app from crashing. Caching can be implemented by checking if translations for a locale already exists before fetching.

### 4.2 Caching Translations

**Standard**: Cache fetched translations in memory to avoid redundant network requests.

**Why**: Improves performance and reduces server load.

**Do This**: Use a simple JavaScript object or a more sophisticated caching library to store translations.

**Don't Do This**: Fetch the same translation file multiple times.

**Example (Caching with a Simple Object):**

"""javascript

const translationCache = {};

async function loadTranslations(locale) {

if (translationCache[locale]) {

return translationCache[locale]; // Return from cache;

}

try {

const response = await fetch("/locales/${locale}.json");

if (!response.ok) {

throw new Error("HTTP error! status: ${response.status}");

}

const data = await response.json();

translationCache[locale] = data; // Store in cache

return data;

} catch (error) {

console.error('Failed to load translations:', error);

return {};

}

"""

This example checks the "translationCache" before making a network request. If the translations are already cached, they are returned immediately, avoiding the network round trip.

## 5. Handling Dynamic Content

### 5.1 Placeholders and Variables

**Standard**: Use placeholders or variables in translation strings to handle dynamic content.

**Why**: Allows you to insert data into translated strings without hardcoding it.

**Do This**:

* Use a consistent placeholder syntax (e.g., "{{variable}}", "{variable}", "%s").

* Provide a mechanism for replacing placeholders with actual values.

* Use libraries supporting pluralization and gender-specific text.

**Don't Do This**:

* Concatenate strings directly with translation keys.

* Use different placeholder syntaxes inconsistently.

**Example (Using Placeholders):**

"""javascript

const translations = {

'en-US': {

'greeting': 'Hello, {{name}}!',

'itemCount': 'You have {{count}} items in your cart.',

'fr-CA': {

'greeting': 'Bonjour, {{name}}!',

'itemCount': 'Vous avez {{count}} articles dans votre panier.',

};

function translate(key, locale, variables = {}) {

let translatedText = translations[locale][key] || key;

for (const variable in variables) {

translatedText = translatedText.replace("{{${variable}}}", variables[variable]);

}

return translatedText;

}

// Usage:

console.log(translate('greeting', 'en-US', { name: 'John' })); // Output: Hello, John!

console.log(translate('itemCount', 'fr-CA', { count: 3 })); // Output: Vous avez 3 articles dans votre panier.

"""

This example defines placeholders using "{{variable}}" syntax. The "translate" function replaces these placeholders with the corresponding values from the "variables" object. Libraries like "i18next" or "Fluent" are more robust choices due to their wider and tested support for complex pluralization rules, gender forms, and number/date formatting.

### 5.2 Pluralization

**Standard**: Handle pluralization correctly for different languages.

**Why**: Pluralization rules vary significantly between languages.

**Do This**:

* Use a library that supports pluralization (e.g., "i18next", "Fluent").

* Provide different translation strings for different plural forms.

**Don't Do This**:

* Assume that all languages have the same pluralization rules as English. Hardcode singular/plural logic.

**Example (Using i18next for Pluralization):**

"""javascript

// i18next configuration (i18n.js)

import i18n from 'i18next';

import { initReactI18next } from 'react-i18next';

i18n

.use(initReactI18next)

.init({

resources: {

en: {

translation: {

'itemCount_one': 'You have one item in your cart.',

'itemCount_other': 'You have {{count}} items in your cart.',

fr: {

translation: {

'itemCount_one': 'Vous avez un article dans votre panier.',

'itemCount_other': 'Vous avez {{count}} articles dans votre panier.',

lng: 'en',

fallbackLng: 'en',

interpolation: {

escapeValue: false,

});

export default i18n;

// React component

import React from 'react';

import { useTranslation } from 'react-i18next';

function CartSummary({ count }) {

const { t } = useTranslation();

return (

{t('itemCount', { count })}

);

}

// Usage:

// Output: You have one item in your cart.

// Output: You have 3 items in your cart.

"""

In this example, "i18next" is used to handle pluralization. Translation keys are defined with "_one" and "_other" suffixes to specify different plural forms. The "t" function automatically selects the correct form based on the "count" value. "Numeral.js" is often used alongside i18next to format the counts.

## 6. Performance Considerations

### 6.1 Minimizing Lookups

**Standard**: Minimize the number of translation lookups performed during rendering.

**Why**: Reduces the overhead of looking up translations for each component.

**Do This**: Cache translated strings in components or use memoization techniques.

**Don't Do This**: Perform translation lookups in render methods repeatedly without caching.

**Example (Caching Translated Strings):**

"""jsx

import React, { useState, useEffect } from 'react';

import { useTranslation } from 'react-i18next';

function MyComponent() {

const { t } = useTranslation();

const [greeting, setGreeting] = useState('');

useEffect(() => {

// Cache the translated string

setGreeting(t('greeting', { name: 'John' }));

}, [t]);

return (

{greeting}

);

}

"""

This example caches the translated "greeting" string in a state variable. The translation lookup is performed only once when the component mounts. The "useTranslation" hook's "t" function is included in the dependency array for the "useEffect" hook to account for changes to the translation function itself which happens on language changes.

### 6.2 Optimizing Translation Loading

**Standard**: Optimize the loading of translation files to reduce initial load time.

**Why**: A large translation file can significantly impact the application's startup performance.

**Do This**:

* Use code splitting to load translation files on demand.

* Compress translation files to reduce their size.

* Use a CDN to deliver translation files from a location close to the user.

**Don't Do This**:

* Load all translation files at application startup.

* Serve uncompressed translation files.

## 7. Security Considerations

### 7.1 Preventing XSS Attacks

**Standard**: Prevent cross-site scripting (XSS) attacks when displaying translated content.

**Why**: Malicious translation strings can inject JavaScript code into the application.

**Do This**:

* Sanitize user-provided content before including it in translation strings.

* Use a templating engine that automatically escapes HTML entities.

**Don't Do This**:

* Directly insert user-provided content into translation strings without sanitization.

* Disable HTML escaping in the templating engine.

**Example (Sanitizing User Input):**

"""javascript

function sanitize(text) {

const map = {

'&': '&',

'<': '<',

'>': '>',

'"': '"',

"'": '''

};

return text.replace(/[&<>"']/g, function(m) { return map[m]; });

}

const translations = {

'en-US': {

'comment': 'User {{username}} said: {{comment}}',

};

function translate(key, locale, variables = {}) {

let translatedText = translations[locale][key] || key;

for (const variable in variables) {

translatedText = translatedText.replace("{{${variable}}}", sanitize(variables[variable]));

}

return translatedText;

}

// Usage:

const userInput = '';

console.log(translate('comment', 'en-US', { username: 'John', comment: userInput }));

// Output: User John said: <script>alert("XSS");</script>

"""

This example uses a "sanitize" function to escape HTML entities in user-provided content before inserting it into the translation string. This prevents the execution of malicious JavaScript code.

### 7.2 Secure Translation Storage

**Standard**: Securely store and manage translation files.

**Why**: Unauthorized modification of translation files can compromise the integrity of the application.

**Do This**:

* Store translation files in a secure location with restricted access.

* Use version control to track changes to translation files.

* Implement a review process for translation changes.

**Don't Do This**:

* Store translation files in a publicly accessible location.

* Allow unauthorized users to modify translation files.

## 8. Conclusion

Adhering to these coding standards for i18n state management ensures that your applications are maintainable, scalable, performant, and secure. By managing state effectively, developers can deliver a consistent and localized user experience across different languages and cultures. As tooling evolves, these guidelines can be adapted as long as the core principles remain the same.

Cline

This guide explains how to effectively use .clinerules with Cline, the AI-powered coding assistant.

Overview

The .clinerules file is a powerful configuration file that helps Cline understand your project's requirements, coding standards, and constraints. When placed in your project's root directory, it automatically guides Cline's behavior and ensures consistency across your codebase.

Key Concepts

Purpose of .clinerules

Defines project-specific guidelines and requirements
Enforces consistent coding standards
Establishes documentation practices
Sets testing and quality requirements
Configures error handling preferences

File Location

Place the .clinerules file in your project's root directory. Cline automatically detects and follows these rules for all files within the project.

Rule Structure

1. Project Overview

# Project Overview
project:
  name: 'Your Project Name'
  description: 'Brief project description'
  stack:
    - technology: 'Framework/Language'
      version: 'X.Y.Z'
    - technology: 'Database'
      version: 'X.Y.Z'

2. Code Standards

# Code Standards
standards:
  style:
    - 'Use consistent indentation (2 spaces)'
    - 'Follow language-specific naming conventions'
  documentation:
    - 'Include JSDoc comments for all functions'
    - 'Maintain up-to-date README files'
  testing:
    - 'Write unit tests for all new features'
    - 'Maintain minimum 80% code coverage'

3. Security Rules

# Security Guidelines
security:
  authentication:
    - 'Implement proper token validation'
    - 'Use environment variables for secrets'
  dataProtection:
    - 'Sanitize all user inputs'
    - 'Implement proper error handling'

Best Practices

Writing Effective Rules

Be Specific
- Use clear, actionable language
- Provide examples where helpful
- Define measurable criteria
Maintain Organization
- Group related rules together
- Use consistent formatting
- Keep critical rules at the top
Regular Updates
- Review rules periodically
- Update based on team feedback
- Document changes in version control

Common Patterns

# Common Patterns Example
patterns:
  components:
    - pattern: 'Use functional components by default'
    - pattern: 'Implement error boundaries for component trees'
  stateManagement:
    - pattern: 'Use React Query for server state'
    - pattern: 'Implement proper loading states'

Integration with Development Workflow

Using with Version Control

Commit the Rules
- Include .clinerules in version control
- Document rule changes in commit messages
- Review rule changes as part of PR process
Team Collaboration
- Discuss rule changes with team
- Maintain changelog for rule updates
- Ensure all team members understand rules

Troubleshooting

Common Issues

Rules Not Being Applied
- Verify file location (must be in root directory)
- Check file formatting
- Ensure Cline has access to the file
Conflicting Rules
- Review rule hierarchy
- Resolve conflicts explicitly
- Document rule precedence
Performance Considerations
- Keep rules concise and focused
- Avoid overly complex rule structures
- Regular cleanup of obsolete rules

Examples

Basic Project Setup

# Basic .clinerules Example
project:
  name: 'Web Application'
  type: 'Next.js Frontend'
  standards:
    - 'Use TypeScript for all new code'
    - 'Follow React best practices'
    - 'Implement proper error handling'

testing:
  unit:
    - 'Jest for unit tests'
    - 'React Testing Library for components'
  e2e:
    - 'Cypress for end-to-end testing'

documentation:
  required:
    - 'README.md in each major directory'
    - 'JSDoc comments for public APIs'
    - 'Changelog updates for all changes'

Advanced Configuration

# Advanced .clinerules Example
project:
  name: 'Enterprise Application'
  compliance:
    - 'GDPR requirements'
    - 'WCAG 2.1 AA accessibility'

architecture:
  patterns:
    - 'Clean Architecture principles'
    - 'Domain-Driven Design concepts'

security:
  requirements:
    - 'OAuth 2.0 authentication'
    - 'Rate limiting on all APIs'
    - 'Input validation with Zod'

State Management Standards for Internationalization

Cline

Overview

Key Concepts

Purpose of .clinerules

File Location

Rule Structure

1. Project Overview

2. Code Standards

3. Security Rules

Best Practices

Writing Effective Rules

Common Patterns

Integration with Development Workflow

Using with Version Control

Troubleshooting

Common Issues

Examples

Basic Project Setup

Advanced Configuration

Related Rules

Tooling and Ecosystem Standards for Internationalization

Testing Methodologies Standards for Internationalization

Core Architecture Standards for Internationalization

Component Design Standards for Internationalization

Performance Optimization Standards for Internationalization