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

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')?> 

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

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

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

Answer 1

EDITНе видел, что это было отмечено Smarty. Не обращайте внимания на мой ответ, если вам нужен конкретный ответ Smarty.

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

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

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

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

Answer 2

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

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

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

{{user_quota_exeeded}} 

или

{{user_quota_exeeded_alert}} 

В конечном счете, если ваша «реальная строка» получает изменилась и «фиктивный параметр» в шаблоне Безразлично» t, он обманет некоторых ваших сотрудников/клиентов/...

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

Подробнее об обозначениях на wikipedia.

Answer 3

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

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

Answer 4

Все это были отличные ответы, замечательные идеи, ребята.

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

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

Другой вопрос, который попал мне в голову, - это штраф за исполнение.

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

Что думают?