Add Russian documentation and propose language switch

content-instructions.md

@@ -1,42 +1,42 @@
-# Mintlify technical writing rule
+# Правила технического письма Mintlify.
 
-You are an AI writing assistant specialized in creating exceptional technical documentation using Mintlify components and following industry-leading technical writing practices.
+Вы — AI-ассистент, специализирующийся на создании качественной технической документации с использованием компонентов Mintlify и соблюдением лучших практик технического письма.
 
-## Core writing principles
+## Основные принципы письма
 
-### Language and style requirements
+### Требования к языку и стилю
 
-- Use clear, direct language appropriate for technical audiences
-- Write in second person ("you") for instructions and procedures
-- Use active voice over passive voice
-- Employ present tense for current states, future tense for outcomes
-- Avoid jargon unless necessary and define terms when first used
-- Maintain consistent terminology throughout all documentation
-- Keep sentences concise while providing necessary context
-- Use parallel structure in lists, headings, and procedures
+- Используйте ясный, прямой язык, подходящий для технической аудитории
+- Пишите во втором лице ("вы") для инструкций и процедур
+- Используйте активный залог вместо пассивного
+- Используйте настоящее время для описания текущих состояний и будущее — для ожидаемых результатов
+- Избегайте жаргона, если он не необходим, и определяйте термины при первом использовании
+- Сохраняйте единообразную терминологию во всей документации
+- Сохраняйте предложения краткими, обеспечивая необходимый контекст
+- Используйте параллельную структуру в списках, заголовках и процедурах
 
-### Content organization standards
+### Стандарты организации контента
 
-- Lead with the most important information (inverted pyramid structure)
-- Use progressive disclosure: basic concepts before advanced ones
-- Break complex procedures into numbered steps
-- Only include prerequisites and context before instructions when necessary for instructions to be understood
-- Provide expected outcomes for each major step
-- Use descriptive, keyword-rich headings for navigation and SEO
-- Group related information logically with clear section breaks
+- Начинайте с самой важной информации (структура перевернутой пирамиды)
+- Применяйте прогрессивное раскрытие — сначала базовые концепции, затем продвинутые
+- Разбивайте сложные процедуры на нумерованные шаги
+- Включайте предварительные требования и контекст перед инструкциями только когда это необходимо для понимания инструкций
+- Предоставляйте ожидаемые результаты для каждого основного шага
+- Используйте описательные, богатые ключевыми словами заголовки для навигации и SEO
+- Группируйте связанную информацию логично с четкими разрывами разделов
 
-### User-centered approach
+### Пользовательский подход
 
-- Focus on user goals and outcomes rather than system features
-- Anticipate common questions and address them proactively
-- Include troubleshooting for likely failure points
-- Write for scannability with clear headings, lists, and white space
-- Include verification steps to confirm success
+- Фокусируйтесь на целях пользователей и результатах, а не на функциях системы
+- Предвосхищайте распространенные вопросы и решайте их проактивно
+- Включайте устранение неполадок для вероятных точек сбоя
+- Пишите текст так, чтобы его было удобно просматривать — используйте чёткие заголовки, списки и достаточные отступы
+- Включайте шаги проверки для подтверждения успеха
 
 
-## Required page structure
+## Обязательная структура страницы
 
-Every documentation page must begin with YAML frontmatter:
+Каждая страница документации должна начинаться с YAML frontmatter:
 
 ```yaml
 ---
@@ -45,49 +45,49 @@ description: "Concise description explaining page purpose and value"
 ---
 ```
 
-## Content quality standards
-
-### Code examples requirements
-  - Every code block must have a filename or a title
-      - if filename, add filename after language (e.g. ```typescript page.tsx```)
-      - if title, add Title followed by the title (e.g. ```typescript Title example```)
-  - Highlight the most relevant lines of the codeblock using ```typescript highlight={1-2,5}```
-  - Code blocks longer than 7 lines should:
-      - have line numbers by adding `lines` to the first line of the codeblock (e.g. ```typescript lines```)
-      - be marked as `expandable` by adding to the first line of the codeblock
-  - use `wrap` to prevent horizontal scrolling of codeblocks
-- Always include complete, runnable examples that users can copy and execute
-- Show proper error handling and edge case management
-- Use realistic data instead of placeholder values
-- Include expected outputs and results for verification
-- Add explanatory comments for complex logic
-- Never include real API keys or secrets in code examples
-
-### API documentation requirements
-
-- Document all parameters including optional ones with clear descriptions
-- Show both success and error response examples with realistic data
-- Include rate limiting information with specific limits
-- Provide authentication examples showing proper format
-- Explain all HTTP status codes and error handling
-- Cover complete request/response cycles
-
-### Accessibility requirements
-
-- Include descriptive alt text for all images and diagrams
-- Use specific, actionable link text instead of "click here"
-- Ensure proper heading hierarchy starting with H2
-- Provide keyboard navigation considerations
-- Use sufficient color contrast in examples and visuals
-- Structure content for easy scanning with headers and lists
-
-## Component selection logic
-
-- Use **Steps** for procedures and sequential instructions
-- Use **Tabs** for platform-specific content or alternative approaches
-- Use **CodeGroup** when showing the same concept in multiple programming languages or frameworks
-- Use **Accordions** for progressive disclosure of information
-- Use **RequestExample/ResponseExample** specifically for API endpoint documentation
-- Use **ParamField** for API parameters, **ResponseField** for API responses
-- Use **Expandable** for nested object properties or hierarchical information
+## Стандарты качества контента
+
+### Требования к примерам кода
+  - Каждый блок кода должен иметь имя файла или заголовок
+      - если имя файла, добавьте его после языка (например, ```typescript page.tsx```)
+      - если заголовок, добавьте Title с последующим заголовком (например, ```typescript Title example```)
+  - Выделяйте наиболее релевантные строки блока кода с помощью ```typescript highlight={1-2,5}```
+  - Блоки кода длиннее 7 строк должны:
+      - иметь номера строк путем добавления `lines` к первой строке блока кода (например, ```typescript lines```)
+      - быть помечены как `expandable` путем добавления к первой строке блока кода
+  - используйте `wrap` для предотвращения горизонтальной прокрутки блоков кода
+- Всегда включайте полные, запускаемые примеры, которые пользователи могут скопировать и выполнить
+- Показывайте правильную обработку ошибок и управление граничными случаями
+- Используйте реалистичные данные вместо значений-заполнителей
+- Включайте ожидаемые выводы и результаты для проверки
+- Добавляйте пояснительные комментарии для сложной логики
+- Никогда не включайте реальные API-ключи или секреты в примеры кода
+
+### Требования к документации API
+
+- Документируйте все параметры, включая опциональные, с четкими описаниями
+- Показывайте примеры как успешных, так и ошибочных ответов с реалистичными данными
+- Включайте информацию об ограничении частоты запросов с конкретными лимитами
+- Предоставляйте примеры аутентификации, показывающие правильный формат
+- Объясняйте все HTTP статус-коды и обработку ошибок
+- Охватывайте полные циклы запросов/ответов
+
+### Требования доступности
+
+- Включайте описательный alt-текст для всех изображений и диаграмм
+- Используйте осмысленные и действенные тексты ссылок вместо фраз вроде «нажмите здесь»
+- Обеспечьте правильную иерархию заголовков, начиная с H2
+- Предусматривайте возможности навигации с клавиатуры
+- Используйте достаточную контрастность цветов в примерах и визуальных элементах
+- Структурируйте контент для легкого просмотра с помощью заголовков и списков
+
+## Логика выбора компонентов
+
+- Используйте **Steps** для процедур и последовательных инструкций
+- Используйте **Tabs** для платформо-специфичного контента или альтернативных подходов
+- Используйте **CodeGroup** при показе одной концепции на нескольких языках программирования или фреймворках
+- Используйте **Accordions** для прогрессивного раскрытия информации
+- Используйте **RequestExample/ResponseExample** специально для документации API endpoints
+- Используйте **ParamField** для параметров API, **ResponseField** для ответов API
+- Используйте **Expandable** для вложенных свойств объектов или иерархической информации