Локалізація в php, найкращій практиці чи підході?

Я локалізую свою програму php. У мене є дилема щодо вибору найкращого методу для його здійснення.

Спосіб 1: На даний момент я зберігаю слова, які слід локалізувати у масиві у файлі php

<?php

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

?>

Я використовую функцію для вилучення та повернення кожного слова відповідно до вимог

Спосіб 2: Чи слід використовувати файл txt, у якому зберігається однаковий рядок?

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

Моє запитання - який кращий метод, з точки зору швидкості та зусиль, щоб розробити той самий і чому?

Редагувати: Я хотів би знати, який із двох способів реагує швидше і чому це було б? також будь-яке вдосконалення вищевказаного кодексу буде вдячне !!

PHP має чудові вбудовані можливості для локалізації. Здається, найпоширеніший спосіб - це gettext - цей підручник показує, як він використовується.

Оскільки у PHP 5.3 є також і міжнародна програма, яка пропонує набагато більше можливостей (наприклад, форматувати номери, дати та валюти залежно від мови).

По-перше, gettextце хороший шлях, тому не відмовляйтеся, якщо спочатку це не звучить просто; Однак є й інші варіанти, які корисно знати. Перш ніж пояснити, що давайте спочатку розглянемо ваші пропозиції:

Якщо ви arrayробите це, у вас є досить просте рішення. Хороша річ у тому, що ви можете зберігати свої переклади у сховищі даних, а потім завантажувати їх у свій скрипт PHP як масив, і все. Однак якщо ви хочете статично зберігати масив у файлі PHP, для його редагування потрібен а) PHP-програміст або досвідчений користувач, який знайомий із синтаксисом PHP, просто для редагування файлу; b) синхронізація навіть чотирьох-п'яти різних мовних файлів може бути дуже дратівливим і схильним до помилок.

Що потрібно тут врахувати: як згодом можна додати нові елементи до мовного файлу? Чи можу я залишити це перекладачеві або там повинен бути 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% разів вам не вдасться так далеко зробити мікрооптимізацію, як постійні та змінні проти функціональних дзвінків . Я припускаю, що ваш час як розробник / персонал дорожчий, ніж час процесора.

Оновлення №1

Боже, я розміщую відповідь на запитання за рік. Чому тут ніхто нічого не каже? Нам потрібні сповіщення про ці випадки.

Оновлення №2

З правого боку написано, що це питання за рік; Однак це запитали два роки тому! Тут все вводить в оману!