Структурирование файлов перевода веб-сайтов

Question

Я сталкивался с этой проблемой несколько раз при создании сайтов. Я объясню использование PHP и Laravel в качестве примера, но эта проблема распространена среди нескольких платформ. Об этом уже говорилось в нескольких вопросах ( post1, post2, post3, post4 и некоторых других), но посты не дали хорошего ответа.

Вопрос в том, как лучше структурировать переведенный контент внутри языковых файлов?

В настоящее время я использую Laravel (я не упоминаю версию, потому что и Laravel 4, и Laravel 5 имеют схожие функции локализации, по крайней мере, достаточно похожие для целей этой темы).

Локализация структурирует контент по языковым файлам (en, es,de, fr...), внутри которых может быть несколько файлов.php, которые содержат оператор return, который возвращает многоуровневую словарную структуру.

/lang
    /en
        messages.php
    /es
        messages.php

и файлы содержат что-то вроде этого:

<?php    
return [

    'example1' => 'example message for value exaple-key',
    'example2' => [
        'sub-example' => 'example message for example1.sub.example',
    ],    
];

и вызов этого делается следующим образом:

//Laravel 5    
trans('messages.example1'); //outputs 'example message for value exaple-key'
trans('messages.example2.sub-example'); //outputs 'example message for example1.sub.example'

//Laravel 4   
Lang::get('messages.example1'); //outputs 'example message for value exaple-key'
Lang::get('messages.example2.sub-example'); //outputs 'example message for example1.sub.example'

На ум приходят несколько методов группировки:

1. по содержанию сайта

   пример: homepage.php, page1.php, page2.php...

2. по логическому домену:

   пример: auth.php, validation.php, pagination.php...

3. по HTML:

   пример: buttons.php, popup_messages.php, form_data.php...

4. по прямой линии:

   пример: simple_words.php, phrases.php... и чем содержать контент, как 'password-to-short' => 'your password is to long'

5. Некоторый гибрид / комбинация упомянутых ранее

Все они имеют некоторые очевидные преимущества и недостатки, и я не буду пытаться сказать, что пятый вариант, скорее всего, является лучшим решением, но все еще остается проблема, где провести черту, чтобы получить минимальное дублирование фраз и контента.

Еще одна проблема состоит в том, как решить проблему заглавных первых символов в некоторых случаях и строчных в других случаях, а также знаков препинания на концах.

Я действительно исследовал эту проблему, но нет четких указаний и / или хороших примеров, которые можно было бы изучить.

Все мнения приветствуются.

Answer 1

Я склонен группировать функциональность в моих приложениях Laravel в автономные "компоненты". Например, я недавно работал над функциональностью кампании электронной почты для приложения, поэтому поместите класс поставщика услуг, модели, классы обслуживания в папку app / Email.

Имея это в виду, я организую свои переводы аналогичным образом. Поэтому, хотя в этом проекте мы не переводим строки, я бы создал файл resources / assets / lang / en / email.php и поместил туда переведенные строки для компонента электронной почты.

Так что в другом проекте моя структура каталогов может выглядеть так:

• /Ресурсы
  • / языки
    • / ан
      • auth.php
      • email.php
      • events.php
      • news.php
      • pagination.php
      • passwords.php
      • validation.php

Надеюсь это поможет.

Answer 2

По моему опыту, нет причин иметь другие группы, кроме попыток использовать ваши переводы где-то еще. Я обычно помещаю все свои сообщения проекта в группу с именем app, и для каждой из моих общих библиотек я использую отдельное имя группы (потому что я могу использовать их в других проектах). Примером сообщения об ошибке входа в систему на моем сайте будет

trans('app.username_and_password_do_not_match')

и если он находится в сторонней библиотеке с именем Auth, это будет

trans('auth.username_and_password_do_not_match')

И не забудьте написать полное сообщение в качестве ключа сообщения вместо использования коротких имен (например, app.login.fail). Таким образом, вам не нужно проверять содержимое сайта для каждого перевода.

Я не совсем понял вашу последнюю проблему, поэтому вы можете немного ее прояснить.

Answer 3

Я бы выбрал вариант № 4, чтобы у вас было что-то вроде этого:

/lang/
    /en 
      messages.php
      words.php
    /fr
      message.php
      words.php
    /de
      messages.php
      words.php

Это делает несколько вещей:

• Все очень четко сегментируется. Вы знаете, какой язык найти где. И вы знаете, что в файле, связанном с языком.
• Вышеуказанное облегчает обслуживание в будущем, потому что вы можете найти вещи.
• Это дает вам файлы, по языку, которые могут быть переведены отдельно.
• Он помещает все сообщения в одно четко определенное место.

Стоит отметить, что если ваше приложение становится ДЕЙСТВИТЕЛЬНО большим и ДЕЙСТВИТЕЛЬНО международным, вы можете использовать вместо этого языковые коды ISO. Например, европейский португальский (pt_PT) и бразильский португальский отличаются друг от друга, и с глобальной аудиторией вы, вероятно, захотите охватить оба.