PHPSTORM fajnie podpowiada użyte indeksy więc warto trzymać się jakiegoś standardu, a nie potrafię wybrać najlepszego, a teraz na dodatek muszę przepisać 10% plików językowych bo nie można użyć czegoś takiego:
'teacher.name' => 'Nauczyciel', 'teacher.name.placeholder' => 'Podaj imię i nazwisko',
Ponieważ biblioteki które pozwalają na zarządzanie plikami językowymi dumpują potem to wszystko do tablicy i dot notation jest zmienione na zagnieżdżenia. Tak więc spowoduje to nadpisanie i trzeba stosować np.
'teacher.name.label' => 'Nauczyciel', 'teacher.name.placeholder' => 'Podaj imię i nazwisko',
To tyle przestrogi, może kiedyś komu zaoszczędzi to czasu, ja teraz mam około 200 linijek CTR+F i CTR+R

Wracając do tematu podzielcie się swoimi konwencjami. Moje przemyślenia:
Na pewno warto nie bać się podziału na pliki. Ja tego żałuje bo teraz gdy pliki mają 2500 linijek to przy edytorach webowych troszkę przymula.
Pliki podzielone na jakieś ogólne, wspólne np. app.php czy system.php oraz na większe moduły (fragmenty systemu).
W samych plikach stosuje podgrupy np.
button.add => Dodaj
button.delete => Usuń
Przy PHPSTORM taka konwencja mega się sprawdza, nie musisz zaglądać do pliku językowej tylko bez problemu na "czuja" zakodujesz widok.
Problem z konwencją mam już przy konkretnym widoku, powiedzmy formularz z nauczycielem.
Plik modules.php
teacher.title => Dodawanie nauczyciela, // Konwencja na tytuł strony, title, text główny?
teacher.form.name.label' => 'Imię',
teacher.form.name.text' => 'Minimum 2 znaki',
teacher.form.name.placeholder' => 'Proszę wprowadzić imię',
Wygląda w porządku, ale już reusable troszkę kuleje, bo wszystkie labele można by użyć w widoku typu "show" czyli profilu nauczyciela.
<span>{{ __('teacher.form.name.label') }}</span>: {{ $teacher->name }}
Troszkę to nie pasuje bo to nie formularz, znowu przejrzyściej byłoby dla mnie:
<span>{{ __('teacher.name') }}</span>: {{ $teacher->name }}
Wtedy, bez zaglądania w pliki wiem na 99% co jest pod tym tłumaczeniem.
teacher.name i opcjonalne teacher.name.placeholder nie wchodzi w grę, tak właśnie robiłem i teraz żałuje (patrz wyżej).
Ewentualnie teacher.name-placeholder lub name_placeholder. Jaki widzicie w ogóle _ - w nazwach? _ staram się używać wyłącznie jako spacja (dwu wyrazowe zmienne), nigdy w innym celu.
Macie jakieś swoje przemyślenia, może swoje koncepcje? Na stacku nic nie znalazłem, jest dużo o konwencjach nazewnictwa zmiennych, klas czy plików, ale kluczy w plikach językowych nie.