Локализация в php, лучшая практика или подход?

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

Способ 1: в настоящее время я храню слова для локализации в массиве в файле php

<?php

$values = array (
                        'welcome' => 'bienvenida'
                ); 

?>

Я использую функцию, чтобы извлечь и вернуть каждое слово в соответствии с требованием

Способ 2: я должен использовать текстовый файл, который хранит строку того же самого?

<?php
$welcome = 'bienvenida'; 
?>

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

Изменить: я хотел бы знать, какой метод из двух быстрее реагирует и почему это будет? Кроме того, любые улучшения в приведенном выше коде будет приветствоваться!

PHP имеет большие встроенные возможности для локализации. Наиболее распространенный способ - gettext - в этом уроке показано, как он используется.

Начиная с PHP 5.3 есть также intl, который предлагает гораздо больше функций (например, для форматирования чисел, дат и валют в зависимости от локали).

Во-первых, gettextэто хороший способ, так что не отмахивайтесь, если поначалу это звучит нелегко; Однако есть и другие варианты, которые полезно знать. Прежде чем объяснить это, давайте сначала рассмотрим ваши предложения:

Если вы arrayделаете это, у вас есть довольно простое решение. Хорошо, что вы можете хранить свои переводы в хранилище данных, а затем загружать их в свой PHP-скрипт в виде массива, и все. Однако, если вы хотите хранить массив статически в файле PHP, то для его редактирования необходимо: а) программист PHP или опытный пользователь, знакомый с синтаксисом PHP, просто для редактирования файла; б) синхронизация даже четырех или пяти различных языковых файлов. может быть довольно раздражающим и склонным к ошибкам.

Что вам нужно учитывать здесь: Как позже можно добавить новые элементы в языковой файл? Могу ли я оставить это на усмотрение переводчика или должен быть программист на PHP?

Ваш variableспособ сделать это не практично. Зачем? Я предполагаю, что у вас будет несколько функций, по крайней мере, в вашем приложении, верно? Затем вам нужно передать все эти переменные, когда вы вызываете функцию, или вам это нужно global. Если вы думаете, что у вас будет более десяти таких переменных, то я настоятельно рекомендую вам сделать это. Также может быть конфликт имен - вы можете переопределить значение другой переменной с тем же именем, однако это можно решить, добавив префикс, даже такой простой, как символ подчеркивания, так что у вас будет, $_welcomeнапример. В любом случае, будь я на твоем месте, я бы об этом даже не подумал; Не делай этого.

Один хороший способ сделать это - определить константы с префиксом. Так, например, у en.lang.phpвас будет что-то подобное, define( 'LABEL_WELCOME', 'Welcome' );а у no.lang.phpвас будет define ( 'LABEL_WELCOME', 'Velkommen' );. Преимущество использования констант вместо переменных заключается в том, что они всегда доступны в вашем скрипте. Таким образом, вам не нужно вводить или глобально их. По сравнению с массивами и переменными они работают быстрее благодаря способу их обработки в PHP - они занимают меньше места в памяти. Недостаток в том, что вы не можете передать их переводчику, поэтому вам снова нужен PHP-разработчик. Кроме того, синхронизация между файлами может снова стать проблемой.

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

Чтобы обернуть это:

1. Подумайте, как переводчики могут его использовать, и придумали для них решение с рабочим KISS.

2. Подумайте, как вы можете поддерживать синхронизацию между разными языками.

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

4. Подумайте о том, как вы можете применить / изменить логику при получении переводов.

5. Забыл о спектакле. 99,9% от времени вы не получите , что далеко , чтобы сделать микро-оптимизации , как Constant против переменных против вызовов функций . Я предполагаю, что ваше время как разработчика / персонала дороже, чем процессорного времени.

Обновление № 1

Боже мой, я отправляю ответ на годичный вопрос. Почему здесь никто ничего не говорит? Нам нужны оповещения для этих случаев.

Обновление № 2

С правой стороны написано, что это годичный вопрос; Однако это было задано два года назад! Здесь все вводит в заблуждение!