Най-ефективният подход за многоезичен PHP уебсайт

Няколко съображения:

1. Преводи
Кой ще извършва преводите? Хора, които също са свързани със сайта? Преводаческа агенция? Когато използвате Gettext, ще работите с 'pot' (.po) файлове. Тези файлове съдържат идентификатора на съобщението и низа на съобщението (превода). Пример:

msgid "A string to be translated would go here"  
msgstr ""

Сега това изглежда добре и разбираемо за всеки, който трябва да преведе това. Но какво се случва, когато използвате ключови думи, както предлага Майк, вместо пълни изречения? Ако някой трябва да преведе msgstr, наречен "address_home", той или тя няма представа дали това трябва да бъде заглавка "Домашен адрес" или че е пълно изречение. В този случай не забравяйте да добавите коментари към файла точно преди да извикате функцията gettext, както следва:

/// This is a comment that will be included in the pot file for the translators
gettext("ready_for_lost_episode");

Използване на xgettext --add-comments=/// когато създавате .po файловете, ще добавите тези коментари. Въпреки това, не мисля, че Gettext трябва да се използва по този начин. Освен това, ако трябва да добавите коментари с всеки текст, който искате да покажете, вие а) вероятно ще направите грешка в даден момент, б) целият ви скрипт така или иначе ще бъде изпълнен с текстовете, само във формата за коментар, в) коментарите трябва да бъдат поставени директно над Gettext функция, която не винаги е удобна, в зависимост от позицията на функцията във вашия код.

2. Поддръжката
След като вашият сайт се разраства (още повече) и вашите езикови файлове заедно с него, може да стане доста трудно да поддържате всички различни преводи по този начин. Всеки път, когато добавяте текст, трябва да създавате нови файлове, да изпращате файловете на преводачите, да получавате файловете обратно, да се уверите, че структурата е все още непокътната (нетърпеливите преводачи винаги са щастливи да преведат и синтаксиса, правейки целия файл неизползваем :)) и завършете с импортирането на новите преводи. Това е изпълнимо, разбира се, но имайте предвид възможните проблеми в тази връзка с големи сайтове и много различни езици.

Лично аз намирам за по-полезно да управлявам превода с помощта на (прост) CMS, като съхранявате променливите и преводите в база данни и сами експортирате съответните текстове в езикови файлове:

1. добавете променливи към базата данни (напр.:идентификатор, страница, променлива);
2. добавете преводи към тези променливи (напр.:id, varId, language, translation);
3. изберете подходящи променливи и преводи, запишете ги във файл;
4. включете съответния езиков файл във вашия сайт;
5. създайте своя собствена функция за показване на текст на променливи:

text('var'); или може би нещо като __('faq','register','lost_password_text');

Точка 3 може да бъде толкова проста, колкото да изберете всички съответни променливи и преводи от базата данни, да ги поставите в масив и да запишете серлиализирания масив във файл.

Предимства:

1. Поддръжка. Поддържането на текстовете може да бъде много по-лесно за големи проекти. Можете да групирате променливи по страница, секции или други части във вашия сайт, като просто добавите колона към вашата база данни, която определя към коя част от сайта принадлежи тази променлива. По този начин можете бързо да изтеглите списък с всички променливи, използвани в напр. страницата с често задавани въпроси.

2. Превеждам. Можете да покажете променливата с всички преводи на всички различни езици на една страница. Това може да е полезно за хора, които могат да превеждат текстове на няколко езика едновременно. И може да е полезно да видите други преводи, за да усетите контекста, така че преводът да е възможно най-добър. Можете също да направите заявка в базата данни, за да разберете какво е преведено и какво не. Може би добавете времеви печати, за да следите възможните остарели преводи.

3. Достъп. Това зависи от това кой ще превежда. Можете да обвиете CMS с просто влизане, за да предоставите достъп на хора от преводаческа агенция, ако е необходимо, и да им позволите само да променят определени езици или дори определени части от сайта. Ако това не е опция, все пак можете да изведете данните във файл, който може да бъде ръчно преведен и да го импортирате по-късно (въпреки че това може да дойде със същите проблеми, както споменахме по-горе.). Можете да добавите един от преводите, които вече са там (английски или друг основен език) като контекст за преводача.

Като цяло мисля, че ще откриете, че ще имате много повече контрол върху преводите по този начин, особено в дългосрочен план. Не мога да ви кажа нищо за скоростта или ефективността на този подход в сравнение с естествената функция gettext. Но, в зависимост от размера на езиковите файлове, не мисля, че ще има голяма разлика. Ако групирате променливите по страница или раздел, винаги можете да включвате само задължителните части.