Feature request: Option to ignore certain keys?

[jhm-ciberman]

The problem

Example case 1

Certain translation keys should only be present in certain languages and not others.
For example, in the built-in validation.php file, Laravel provides a validation.custom array that can be used to add custom validation messaages for specific rules to make the text more precise:

/*
|--------------------------------------------------------------------------
| Custom Validation Language Lines
|--------------------------------------------------------------------------
|
| Here you may specify custom validation messages for attributes using the
| convention "attribute.rule" to name the lines. This makes it quick to
| specify a specific custom language line for a given attribute rule.
|
*/

'custom' => [
    'email' => [
        // Outputs: "El email ya ha sido registrado" instead of "El campo email ya ha sido registrado" which sounds nicer.
        'unique' => 'El :attribute ya ha sido registrado.',
    ],
    'password' => [
        // Outputs: "La contraseña debe contener más de 8 caracteres" instead of "El campo contraseña debe tener más de 8 caracteres"
        'min' => 'La :attribute debe contener más de :min caracteres',
    ],
],

These kind of customizations only make sense to be defined per language, because in certain languages those lines are fine as they are without needing to customize them further.

Currently this makes a lot of validation files to fail, even they are right:

Missing the translation with key: gl.validation.custom.email
Missing the translation with key: de.validation.custom.email
Missing the translation with key: ca.validation.custom.email
Missing the translation with key: pt.validation.custom.email
Missing the translation with key: eu.validation.custom.email
Missing the translation with key: pt.validation.custom.email
Missing the translation with key: fr.validation.custom.email
Missing the translation with key: gl.validation.custom.email
Missing the translation with key: fr.validation.custom.email
Missing the translation with key: eu.validation.custom.email
Missing the translation with key: de.validation.custom.email
Missing the translation with key: ca.validation.custom.email
Missing the translation with key: gl.validation.custom.password
Missing the translation with key: de.validation.custom.password
Missing the translation with key: ca.validation.custom.password
Missing the translation with key: pt.validation.custom.password
Missing the translation with key: eu.validation.custom.password
Missing the translation with key: pt.validation.custom.password
Missing the translation with key: fr.validation.custom.password
Missing the translation with key: gl.validation.custom.password
Missing the translation with key: fr.validation.custom.password
Missing the translation with key: eu.validation.custom.password
Missing the translation with key: de.validation.custom.password
Missing the translation with key: ca.validation.custom.password

Example case 2

Another scenario is the following: In our application we have to generate dynamic messages like "The shop will be open until tomorrow ar 8:00 AM" or "The shop is closed until 5:30 PM". We use a complex algorithm that involves Carbon::calendar and translation strings and sometimes the resulting translations aren't perfect. That's why we define a custom 'replacements' array like the following:

lang/en/opening-hours.php

'open_24h' => 'Open 24 hours every day',
'open_but_closing_soon' => 'Open. We close soon at :time',
'open_today_24h_but_closing_later' => 'Open today 24 hours. We close at :time',
'open_until' => 'Open until :time',
'closed_holiday' => 'Closed for holiday',
'closed_holiday_until' => 'Closed for holiday until :time',
'closed' => 'Closed',
'closed_but_opening_soon' => 'Closed. We open soon at :time',
'closed_until' => 'Closed until :time',
'calendar' => [
    'sameDay' => '[at] LT',
    'nextDay' => '[tomorrow at] LT',
    'nextWeek' => 'dddd [at] LT',
    'sameElse' => 'LLLL',
],
'replaces' => [
    // Here we make two replacements because those are the required replacements for this locale
    'at tomorrow at' => 'tomorrow at',
    'at at' => 'at',
],

lang/es/opening-hours.php

'open_24h' => 'Abierto 24 horas todos los días',
'open_but_closing_soon' => 'Abierto. Cerramos pronto, a las :time',
'open_today_24h_but_closing_later' => 'Abierto hoy 24 horas. Cerramos :time',
'open_until' => 'Abierto hasta :time',
'closed_holiday' => 'Cerrado por festivo',
'closed_holiday_until' => 'Cerrado por festivo hasta :time',
'closed' => 'Cerrado',
'closed_but_opening_soon' => 'Cerrado. Abrimos pronto, a las :time',
'closed_until' => 'Cerrado hasta :time',
'calendar' => [
    'sameDay' => '[las] LT',
    'nextDay' => '[mañana a las] LT',
    'nextWeek' => '[el] dddd [a las] LT',
    'sameElse' => '[el] D/MM [a las] LT',
],
'replaces' => [
    // Here we make only one replacements because only that is the required replacements for this locale
    'las 1:' => 'la 1:',
],

Proposed solution

It would be pretty nice if we could somehow ignore those fields. For example having support for a simple configuration file like:

config/translations-checker.php

return [

    /*
    |--------------------------------------------------------------------------
    | Laravel Translation Checker
    |--------------------------------------------------------------------------
    |
    | This package allows you to check your Laravel translations for missing
    | keys, unused keys and unused translations.
    | You can ignore some keys by adding them to the 'ignore' array.
    |
    */
    

    'ignore' => [
         'validation.custom',
         'opening-hours.replaces',
     ],

];

[LarsWiegers]

Hi!
First of all, thank you for the amazing issue + the description.
Its amazing and truly appreciated!.

I like your suggestion of adding config items for exclusions, I think we can also use this for the excluded dir option for the command. I will take a look at this tomorrow!

[LarsWiegers]

Can you see if this pr would work for you:
composer require larswiegers/laravel-translations-checker:dev-excluding-keys

[jhm-ciberman]

Hi! This Friday and Monday is a Holiday in my country. I'll be checking in our project's repo this Tuesday.

Thank you!! 🚀🚀🚀😁😁

[LarsWiegers]

@jhm-ciberman can you let me know?

[jhm-ciberman]

@LarsWiegers Hello, sorry for the long delay. I had a super bussy week and I forgot.

I tested in our repo and I found two problems:

Problem 1
The basic functionality works but it shows an incorrect key name:

// lang/es/my-test.php
return [
    'nested' => [
        'foo' => 'bar',
    ],

    'foo' => 'zup',
]

$ sail art translations:check
Missing the translation with key: en.foo
Missing the translation with key: de.foo
Missing the translation with key: en.foo
Missing the translation with key: de.foo

It should show Missing the translation with key: en.my-test.nested.foo instead using the full key name, because otherwise you have no way of telling which of the two keys are missing (my-test.nested.foo or my-test.foo).

Problem 2:

The new excluded_keys functionality doesn't seems to work. The test case is very similar:

// lang/es/my-test.php
return [
    'foo' => 'zup',
]

// config/laravel-translations-checker.php
return [
    'excluded_keys' => [
        'my-test.foo',
        //'my-test.nested.foo', // I tested for nested and deeply nested and it doesn't work neither.ç
        //'foo' // It doesn't work neither with only the leaf key name. 
    ],
];

$ sail art translations:check
Missing the translation with key: en.foo
Missing the translation with key: de.foo

[LarsWiegers]

I pushed a new version can you check if it works now for you?

[LarsWiegers]

@jhm-ciberman please check again :)

[LarsWiegers]

Closing as nothing heard back from @jhm-ciberman

[jhm-ciberman]

Sorry. I no longer work for the company in which I was using this package. And I think my coworker removed this package from the dependencies (nothing personal, they used another entirely different system for translations)

[LarsWiegers]

@jhm-ciberman No worries, thanks for letting me know :)