Более описательный язык String заполнитель?

Question

<?LANG(no_download, 'you are not allowed to download')

вместо

$lang[no_download]

У меня есть то, что я считаю лучшим подходом для встраивания языковых строк в шаблоны.

Практически во всех приложениях PHP преобладающий языковой формат заполнителя похож на <?=$lang['no_download']?> или {{no_download}}. Другим дизайнерам / разработчикам / переводчикам будет трудно понять, что представляют собой заполнители, без ссылки на языковой файл.

Чтобы сделать языковые заполнители более описательными, почему бы нам не включить оригинальную строку вместе с заполнителем? например,

<?=lang( 'no_download' , 'You are not allowed to download this file because you have exceeded your quota' )?>

Второй параметр - это фиктивная переменная, поэтому функция lang () с ним ничего не делает.

С первого взгляда можно подумать, что это слишком многословно, добавляя беспорядок в разметку шаблона. Но, по моему мнению, это недопустимый аргумент, так как языковая строка заняла бы столько же места, сколько заполнитель, если бы не знала язык.

Я хотел бы услышать ваши мысли по этому поводу.

Answer 1

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

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

Ваш ключ должен быть, например:

{{user_quota_exeeded}}

или

{{user_quota_exeeded_alert}}

В конечном итоге, если ваша «настоящая строка» изменится, а «фиктивный параметр» в шаблоне не изменится, это обманет некоторых ваших коллег / клиентов /...

Кроме того, он заставляет вас печатать сообщения дважды.

Подробнее о соглашениях по присвоению имен в wikipedia .

Answer 2

РЕДАКТИРОВАТЬ Не видел, что это было помечено Smarty. Не обращайте внимания на мой ответ, если вам нужен конкретный ответ Smarty.

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

Кроме того, нередко указываются языковые строки по умолчанию в качестве меток перевода. Например, в руководстве Zend Framework это является частью их примера использования . В этом нет ничего плохого, если ваш переводческий адаптер поддерживает это. Если для этого требуются идентификаторы, это не вариант.

Лично я предпочитаю идентификаторы и пытаюсь назвать их в соответствии с их использованием в приложении, например, form.label.login.username или cart.checkout или flashmessage.notice.

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

Answer 3

Это были отличные ответы, отличные идеи, ребята.

Арно, мне хорошо известны соглашения об именах. Мой пример языкового ключа действительно не очень удачно назван, но он был сделан только для того, чтобы служить примером. На протяжении всего процесса перевода моего веб-приложения я сталкивался со строками, которые было трудно суммировать / описать с помощью нескольких строк, поэтому возникла мысль о включении строки языка по умолчанию в качестве меток перевода. Я уверен, что если вы достаточно поработали над переводом, вы столкнетесь с этим сценарием.

В любом случае отрадно видеть, что Zend & Gettext уже приняли этот подход.

Еще один вопрос, который возник у меня в голове, - это снижение производительности.

Будет использовать вызовы функций, например, LANG (), потреблять значительно больше ресурсов, чем просто распечатывать массивы $ lang []?

Что ты думаешь?

Answer 4

Gettext уже делает это. Это выглядит примерно так:

_('Gettext does this already. It goes something like this:');