Improve translation docs and developer experience

[alganet]

The Template class now offers a static façade to quickly obtain the template of a message: Template::from($class, $mode).

This replaces the old way of referencing messages in 2.x (FooException::$defaultTemplates), making existing translation setups easier to migrate.

The documents on translation were updated to feature symfony with an array provider. Duplicated container notes were extracted to a single configuration.md file.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.54%. Comparing base (570ba48) to head (673381d).

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #1675   +/-   ##
=========================================
  Coverage     99.53%   99.54%           
- Complexity      929      934    +5     
=========================================
  Files           190      191    +1     
  Lines          2170     2183   +13     
=========================================
+ Hits           2160     2173   +13     
  Misses           10       10           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

Adds a Template::from($class, $mode) static façade to make validator template lookup easier (supporting translation/migration scenarios), and updates translation/configuration documentation and examples accordingly.

Changes:

• Introduce Respect\Validation\Message\Template::from() for resolving a validator’s Template attribute by template id.
• Update translator feature test and translation docs to reference templates via Template::from(...) instead of hardcoded strings.
• Extract duplicated container notes into a new docs/configuration.md and update docs to link to it.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/Message/Template.php	Adds Template::from() for reflective lookup of template attributes by id.
tests/unit/TemplateTest.php	New unit tests validating Template::from() behavior and error cases.
tests/feature/TranslatorTest.php	Updates translation resources to key off Template::from(...)->default and adds more template-based entries.
docs/migrating-from-v2-to-v3.md	Adds a migration note pointing readers to the updated translation docs.
docs/messages/translation.md	Reworks translation guide and includes Template::from(...)-based examples; links to configuration docs.
docs/messages/placeholder-conversion.md	Replaces duplicated container notes with a link to docs/configuration.md.
docs/configuration.md	New centralized container configuration documentation.
docs/case-sensitiveness.md	Updates example wording to reference v::after wrappers.

Comments suppressed due to low confidence (1)

tests/feature/TranslatorTest.php:44

• The translation resources are clearly Portuguese, but they’re registered under locale "en". This makes the example/test confusing and differs from the docs (which use pt_BR). Consider setting the Translator locale and the addResource locale to "pt_BR" to match the actual translations.

        'and' => 'e',
    ],
    'en',
);

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[henriquemoody]

I see the appeal to add this here, but I think this deserves it's own class. I would also prefer that we do that in just one place. The TemplateResolver does something similar to that, but it also keep an internal state so we don't have to do introspection every time.

For the use-case you're describing here, I think having a TemplateExtractor or something similar would work best, and we could use that extractor on TemplateResolver somehow

[alganet]

The name TemplateExtractor doesn't express the intent of keeping a global store of templates, it just says it extracts them. We know that each validator has a global list of templates, but a developer encountering the name TemplateExtractor might not have that knowledge.

Instead, I went with TemplateRegistry and also registered it in the ContainerRegistry and updated the docs. Now TemplateResolver uses it, and the examples use TemplateRegistry directly to access the global store of templates.

There are further internal refactors to TemplateResolver that can be done now, but I think that is too much scope for this PR. I will probably follow up on them later, since they don't change the public API.