Add language support handling guidelines to Copilot Instructions

[Copilot]

Overview

This PR addresses issue regarding language support handling by adding comprehensive documentation to .github/copilot-instructions.md that clearly explains the critical difference between frontend and backend language support methods.

Problem

The codebase uses two different approaches for language support, and it's essential that developers (and AI assistants) use the correct method based on context:

• Backend: Uses rex_i18n::msg() class or translate:key placeholder
• Frontend (especially fragments in fragments/bootstrap5/ and emails): Uses only Warehouse::getLabel()!

Without clear documentation, it's easy to mix these approaches, which can break the shop's customization capabilities.

Changes

Added detailed language support guidelines in two strategic locations:

1. Fragment Development Guidelines (Section 6)

Enhanced the existing "Labels und Texte" section with:

• Clear separation between Frontend and Backend contexts
• Specific file paths for each context
• Practical code examples for both scenarios
• Explanation of why this separation is essential

2. Code Quality & Best Practices (New Section 7)

Added a new CRITICAL guideline section that includes:

• Explicit DO/DON'T rules for each context
• Visual examples with ✅ correct and ❌ incorrect usage
• Clear reasoning: Frontend labels are customizable by shop operators via Settings → Label, while backend texts are fixed translations

Why This Matters

The separation is critical because:

• Frontend labels (Warehouse::getLabel()) are dynamic and can be customized by shop operators through the backend Settings → Label interface
• Backend texts (rex_i18n::msg()) are static translations stored in /lang/*.lang files that should remain consistent across installations
• Mixing these approaches would break the customization capability that shop operators rely on

Example Usage

Frontend Fragment (Correct):

<h2><?= Warehouse::getLabel('cart_title') ?></h2>

Backend Page (Correct):

$field->setLabel(rex_i18n::msg('warehouse.settings.payment.store_name'));

This documentation ensures consistency across the codebase and prevents common mistakes when developing new features or fixing bugs.

Fixes: Issue about handling language support differently between frontend and backend

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Copilot Instructions: Add information how to handle language support differently between frontend and backend</issue_title>
<issue_description>Backend: rex_i18n class or translate:key placeholder
Frontend (especially frontend fragments in fragments/bootstrap5/ and emails): only Warehouse::getLabel()!</issue_description>

Comments on the Issue (you are @copilot in this section)

Fixes #248

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull Request Overview

This PR adds comprehensive documentation to the Copilot instructions for handling language support differently between frontend and backend contexts in the Warehouse add-on. The documentation clarifies the critical distinction between using Warehouse::getLabel() for frontend fragments and rex_i18n::msg() for backend components.

• Enhanced existing fragment development guidelines with detailed language support rules
• Added a new critical code quality section specifically focused on language support best practices
• Provided clear examples and explanations of why the separation is essential for shop customization