src/Parser/ParserRegistry.php (1)

1-18: LGTM! Consider adding documentation for better maintainability.

The registry pattern implementation is clean and serves its purpose well in the modular architecture. However, the static analysis correctly identifies missing documentation.

Consider adding class and method documentation:

+/**
+ * Registry for managing available parser implementations.
+ */
 class ParserRegistry
 {
+    /**
+     * Get all available parser class names.
+     * 
+     * @return array<int, class-string<ParserInterface>>
+     */
     public static function getAvailableParsers(): array

src/Utility/PathUtility.php (1)

9-25: Solid path normalization logic with minor documentation need.

The implementation correctly handles the main path normalization scenarios. The logic flow is clear and uses modern PHP string functions appropriately.

Consider adding method documentation as suggested by static analysis:

+    /**
+     * Normalize a folder path to be relative with trailing slash.
+     * 
+     * @param string $path The path to normalize
+     * @return string The normalized relative path with trailing slash
+     */
     public static function normalizeFolderPath(string $path): string

Also consider handling the edge case where getcwd() might return false:

-        $cwd = getcwd();
+        $cwd = getcwd() ?: '';

src/Utility/ClassUtility.php (1)

11-30: Well-structured class validation with proper error handling.

The validation logic correctly checks class existence before interface compliance, and the PSR-3 logging integration provides good error reporting. The null handling is appropriate for optional class validation.

Add documentation as suggested by static analysis:

+    /**
+     * Validate that a class exists and implements the required interface.
+     * 
+     * @param string $interface The required interface class name
+     * @param LoggerInterface $logger Logger for error reporting
+     * @param string|null $class The class to validate (null is considered valid)
+     * @return bool True if validation passes, false otherwise
+     */
     public static function validateClass(string $interface, LoggerInterface $logger, ?string $class): bool

src/Validator/ValidatorRegistry.php (1)

7-20: LGTM! Well-implemented registry pattern.

The ValidatorRegistry effectively centralizes validator management with proper type annotations. Consider adding documentation to address the static analysis hints:

+/**
+ * Registry for available translation validators.
+ */
 class ValidatorRegistry
 {
     /**
+     * Get all available validator classes.
+     *
      * @return array<int, class-string<ValidatorInterface>>
      */
     public static function getAvailableValidators(): array

src/FileDetector/Collector.php (1)

34-34: Remove unnecessary method_exists check.

Since ParserRegistry::getAvailableParsers() returns class-string<ParserInterface> types and getSupportedFileExtensions() is defined in the interface, the method_exists() check is redundant.

-                if (method_exists($parserClass, 'getSupportedFileExtensions')) {
                    $files = array_filter(
                        glob($path.'/*'),
                        static fn ($file) => in_array(pathinfo($file, PATHINFO_EXTENSION), $parserClass::getSupportedFileExtensions(), true)
                    );
-                }

src/Validator/ValidatorInterface.php (1)

11-24: LGTM! Excellent interface refactoring with separation of concerns.

The interface refactoring successfully separates file processing, issue rendering, and explanation into distinct methods, improving testability and maintainability. Consider adding comprehensive documentation:

+/**
+ * Interface for translation file validators.
+ */
 interface ValidatorInterface
 {
     /**
+     * Process a single parsed file and return validation issues.
+     *
+     * @param ParserInterface $file The parsed file to validate
      * @return array<string, mixed>
      */
     public function processFile(ParserInterface $file): array;

     /**
+     * Render collected validation issues to console output.
+     *
+     * @param InputInterface $input Console input interface
+     * @param OutputInterface $output Console output interface
      * @param array<string, mixed> $issueSets
+     * @return void
      */
     public function renderIssueSets(InputInterface $input, OutputInterface $output, array $issueSets): void;

+    /**
+     * Provide a textual explanation of what this validator checks.
+     *
+     * @return string Description of the validator's purpose
+     */
     public function explain(): string;

src/Validator/MismatchValidator.php (1)

49-51: Simplify redundant array search operation.

The ternary operation on line 50 searches for a key and returns the value at that position, which is the same as the key itself. This can be simplified.

-                    $this->issues[$key][$file] = in_array($key, $keys, true)
-                        ? $keys[array_search($key, $keys, true)]
-                        : null;
+                    $this->issues[$key][$file] = in_array($key, $keys, true) ? $key : null;

src/Command/ValidateTranslationCommand.php (1)

108-120: Address the TODO comment for nested loop simplification.

The 4-level nested loop structure is indeed complex and should be simplified for better maintainability.

The nested structure processes: parsers → paths → translation sets → validators. Would you like me to help refactor this into a more maintainable structure, perhaps using a method extraction or a different data flow approach?

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

src/FileDetector/Collector.php (1)

28-33: Fix early return logic for invalid paths.

The current implementation returns an empty array when encountering the first invalid path, preventing processing of subsequent valid paths. This could cause the entire validation to fail unnecessarily.

         foreach ($paths as $path) {
             if (!(new Filesystem())->exists($path)) {
-                $this->logger->error('The provided path "'.$path.'" is not a valid directory.');
+                $this->logger?->error('The provided path "'.$path.'" is not a valid directory.');
-
-                return [];
+                continue;
             }

src/FileDetector/Collector.php (3)

36-36: Remove redundant method existence check.

The static analysis tool correctly identifies that this check is always true since ParserInterface guarantees the getSupportedFileExtensions method exists.

-                if (method_exists($parserClass, 'getSupportedFileExtensions')) {
                    $files = array_filter(
                        glob($path.'/*'),
                        static fn ($file) => in_array(pathinfo($file, PATHINFO_EXTENSION), $parserClass::getSupportedFileExtensions(), true)
                    );
-                }

---

37-40: Improve file discovery efficiency and safety.

The current glob approach has several limitations: it doesn't handle recursive directories, may not scale well for large directories, and doesn't validate that results are actually files.

Consider using Symfony's Finder component for more robust file discovery:

+use Symfony\Component\Finder\Finder;

-                    $files = array_filter(
-                        glob($path.'/*'),
-                        static fn ($file) => in_array(pathinfo($file, PATHINFO_EXTENSION), $parserClass::getSupportedFileExtensions(), true)
-                    );
+                    $finder = new Finder();
+                    $finder->files()->in($path)->name('/\.('.implode('|', $parserClass::getSupportedFileExtensions()).')$/');
+                    $files = array_map(fn ($file) => $file->getPathname(), iterator_to_array($finder));

---

47-48: Apply consistent null-safe logging.

-                        $this->logger->debug('No files found for parser class "'.$parserClass.'" in path "'.$path.'".');
+                        $this->logger?->debug('No files found for parser class "'.$parserClass.'" in path "'.$path.'".');

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro