Support for array translations

[N1ebieski]

Fixes #300, #428

This PR adds support for array translations for example:

resources/lang/en/validation.php:

'attributes' => [
    'question' => [
        'email' => 'email address',
    ],
]

Currently, the code:

__('validation.attributes.question')

shows:

Translation [validation.attributes.question] not found.Laravel Extension(translation)

but this key exists, it's only an array with nested elements.

This PR adds support for such keys for hovering and linking to the first element in the array. However, the value is not shown in the hover, because it's an array.

This code needs futher refactoring and testing.

[tharlei]

Nice PR! 🚀

It is also interesting to apply it to the locale that I passed to the __() or trans() method

Example:

__('validation.attributes.question', locale: 'pt-BR')

Check the pt-BR folder this transcription

[N1ebieski]

@tharlei #330

[rmartinoscar]

Hey this works perfectly unless we have nested arrays without named key could this also be addressed ?

[N1ebieski]

@rmartinoscar for me, this works:

Something like this, doesn't work:

I'm afraid that feature would be impossible with the current parser.

[rmartinoscar]

Yes cause you have

return [
    'requirements' => [
        'sections' => [
            '0' => [
                'title' => 'PHP version',
            ],
            '1' => [
                'title' => 'PHP extensions',
            ],
        ]
    ]
];;

and i have which works but the extension doesn't like it

return [
    'requirements' => [
        'sections' => [
            [
                'title' => 'PHP version',
            ],
            [
                'title' => 'PHP extensions',
            ],
        ]
    ]
];;

[rmartinoscar]

This is also fine

[jacobmllr95]

@joetannenbaum Would love to see that merged :)
@N1ebieski Thanks for the great improvements to translations!

[TitasGailius]

@N1ebieski Thanks for jumping on this! I appreciate the fix, but I'd like to take a slightly different approach to keep the logic clean.

Instead of wrapping getTranslationItemByName, let's update the function itself to handle nesting natively. To do that, we'll need to adjust the TranslationItem type so the value can represent more than just a single string, essentially allowing it to hold nested structures.

Something like this:

export interface TranslationItem {
    [key: string]: {
-       value: string;
+       value: string | Record<string, unknown>;
        path: string;
        line: number;
        params: string[];
    };
}

This way, we keep the implementation centralized rather than adding layers around it.

[N1ebieski]

@TitasGailius I’ll hold off on refactoring this PR until you decide on #443, because some of the logic is related.