Every user facing string in the library goes through the Language instance, except the argument and option validation messages, which are built with English string concatenation in Command::validateDefinitions() (src/Command.php:359 and src/Command.php:377):
$errors[] = $label . ' "' . $key . '" is required.';
$errors[] = $label . ' "' . $key . '" must be of type ' . $type . '.';
The $label value (argument / option) is hardcoded English at the call site too.
So running a console in es or pt-br gets translated command listings, help and "command not found", then an English validation error.
Suggested keys, following the existing naming in src/Languages/en/cli.php:
'argument' => 'argument',
'option' => 'option',
'validation.required' => '{0} "{1}" is required.',
'validation.type' => '{0} "{1}" must be of type {2}.',
All three language files need the new keys. A test asserting that en, es and pt-br expose the same key set would stop them drifting, which nothing currently checks.
Every user facing string in the library goes through the
Languageinstance, except the argument and option validation messages, which are built with English string concatenation inCommand::validateDefinitions()(src/Command.php:359andsrc/Command.php:377):The
$labelvalue (argument/option) is hardcoded English at the call site too.So running a console in
esorpt-brgets translated command listings, help and "command not found", then an English validation error.Suggested keys, following the existing naming in
src/Languages/en/cli.php:All three language files need the new keys. A test asserting that
en,esandpt-brexpose the same key set would stop them drifting, which nothing currently checks.