Изпечатай

[runtime]

Здр, правя си едно семпло сайтче, което ще е на 4 езика. Езика ми е в папки languages и под-папка за съутветния език "bg",'eng" и т.н.

Всичко си направих, но стигнах до момента с категории и подкатегории И тук точно ми е въпроса и да дадете мнение как ще е по-добре да се направи
Ако вкарам категориите в база данни и да се четат от там ще трябва да се прави по една колона за всеки език, което е тъпо защото утре може да решим да сложим и n на брой езици и трябва да се ходи по базата и да се създава нова колона ... Мен ми хрумна и за сега ми се стъва най-читаво изпълнение да си ги сложа в едно .php с масиви за съответно категория и подкатегория и при избор да се редактира за всеки един език, а и така до някъде се прави оптимизация да не чете всяка дума от базата ...

Та според вас, как е най-добре база или масив? Ако е масив ще е трудно за разчитане от 3-ти лица
Колебая се

Варианта с масива ми е нещо от сорта на:

$arr = array("cat1" => array("cat1_subcat1","cat1_subcat2","cat1_subcat3"),cat2 => array("cat2_subcat1","cat2_subcat2","cat2_subcat3"));

foreach($arr as $key => $value){
  echo "$key =>";
   foreach($arr[$key] as $key2 => $value2){
       echo "$value2    ";
}
echo "<br>";
}

[botzko]

Не виждам какво му е по-лесното с масивите. А и начина който си дал е малко глупав (поне на мене така ми се струва). Аз бих ползвал базата като имам таблица DICTIONARY със съответните колони:
LANGUAGE, CODE, VALUE. Като в LANGUAGE слагаш езика, в CODE някакъв код за самата дума и във VALUE превода.
Пример:

Код:

LANGUAGE    CODE    VALUE
BG                test       Тест
EN                test        Test
DEF               test       Test

Слагай си колкото си искаш езици и няма да трябва да добавяш нови колони в таблицата. Даже ако си поиграеш малко можеш да направиш така, че ако нещо не е преведено да използва DEF превода.

Другото е да си ползваш масиви ама не и така както си ги направил ти. Направи си файлове dictionary_[език].php, например dictionry_BG.php, dictionary_EN.php и така нататък. В тях масива да е по следния начин:

Код:

dicitonary = array(
KEY=>TRANSLATE,
KEY=>TRANSLATE,
.......
)

Винаги знаеш кои е езика (да речем, че се пази в $_SESSION['LANG']) просто трябва да заредиш нужния файл:

Код:

require_once('dictionary_' . $_SESSION['LANG'] . '.php');

Така ще е по четаемо и за трети лица.

Успех.

[VladSun]

Моето решение за многоезични сайотве с ДБ съдържание е следното:
- правиш таблица за езиците;
- правиш си таблица за един език (bg);
- вадиш всичко, което е зависимо от езика във втора таблица заедно с референция (FK) към в първата и референция към таблицата с езиците;

table language

Код

GeSHi (SQL):
id
language_name

table good

Код

GeSHi (SQL):
id
short_description
long_description
picture_file_name

=======================

=>


table language

Код

GeSHi (SQL):
id
language_name

table good

Код

GeSHi (SQL):
id
picture_file_name

table good_translation

Код

GeSHi (SQL):
FK_good_id
FK_language_id
short_description
long_description

[gotha]

Разбира се, винаги можеш да си извадиш всички стрингове в един file, да го копираш три пъти - eдин път с разширение .en, eдин път с разширение .de и един път с разширение .bg.
И в трите файла имаш променлива $welcome
в първия пише:

Код:

$welcome = "welcome";

във втория:

Код:

$welcome = "willcommen"; 
//немския не ми е толкова добър като едно време, може и да не се пише така :)

в третия

Код:

$welcome = "добре дошли";

И после зависи от това какъв език е избрал потребителя си inclide-ваш съответния файл, от където пък автоматично си се добавят променливите и съответно превода.
Този вариант за мен е най-елементарен и най-лесен за реализиране при условие, че искаш само да добавяш нови езици, без да променяш съдържанието на основния сайт.
Защото ако искаш да го преведеш на испански примерно, просто копираш още един път файла и попълваш нещата. Ако обаче искаш да добавиш променлива $goodbye, нещата стават прекалено туткави и не е работа да се занимаваш.

Ти си преценяваш.
Аз бях използвал този начин при един сайт, който знаех, че след това почти няма да се бута по кода му и няма да има кой знае какви промени, но ако ще праиш много промени по преводите не ти го препоръчвам.

[runtime]

botzko: Това, което казваш е вярно, както и предложението ти, но нямах това в предвид. Ако се загледаш в моя пример, въпреки, че не е четливо издаржан, то идеята му е че всяка категория (масив) има вложен масив за суб категорията, това че е на 1 ред всичко си е моя грешка можеше да подредя кода, но за пробата не го направих и ето, че видях как това се отразява

VladSun: Много благодаря за примера, ако избера все пак база данни определено ще се съобразя с твоя пример и най-вероятно така ще го изградя ... Добро решение е, но пък дилемата все още ми е файл или база

gotha: Много благодаря и за твоя отговор, но ти явно не схвана въпроса ми. Аз знам как да си дифинирам константи за езика и да размножа файловете, но идята тук ми беше друга. Иначе да като цяло съм си устроил превода с DEFINE("variable","stoinost") и имено поради тази причина се чудя дали е удачно да се ползва и база данни за отделни фрагменти от превода или да са си на файл. А и твоя пример с променливи не е много за предпочитане пред константите защото може да се допусне дублиране на променливи, което да доведе до грешки в даден момент.

Общо взето ме интересува, кой според вас е най-удачният вариант за изграждането на мултиезичен сайт. Превода да е в база данни или в константи и масиви?

Случая с категория и съответна суб-категория най-удачно да е в база данни, но пък почнах с файлове Не е късно да променя нещата и за това питам ( искам мнение ), което в книгите обикновенно не го пише, кой вариант според вас е най-удачен И двата са достатъчно разпространени, но ме гложди само вложените масиви, а те няма как да не са ако има суб-категории

Но от друга страна пък ако е с база данни при всяка смяна на страницата ще се извършва четене от базата за съответните стойности за езика.
Вариант 3: База и файл на мен не ми се нрави изобщо ... много разкъсана става работата

[edmon]

хм според мен не е толкова важно самото решение а спецификата.
ако има 50-60 изречения които трябва да се преведат не си заслужава да се ползва база.
ако има големи пасажи от абзаци си заслужава.

Няма по барза база данни от файловата система

По някой път е по-лошо да се раздобяват нещатата от колкото да са на едно място.
Вместо /ланг/<език>/фаил.пхп е по-добре /ланг/<език>.пхп

[VladSun]

Но от друга страна пък ако е с база данни при всяка смяна на страницата ще се извършва четене от базата за съответните стойности за езика.

Повечето frameworks (zend, cake, CI И т.н.) имат кеширане на резултатите от заявките.

[VladSun]

Аз имам едно решение, което много ми хареса как се получи - "превод при поискване".
Дефинирам си 3 таблици с референции помеждум им: language, context, item
При зареждането на съответното view към action controller-а се извиква $language->loadContext($controller, $action), която зарежда всички преводи за съответната страница
Имам една функция, която "иска" превода - $language->getTranslation('itemName');
Ако преводът вече съществува в ДБ-то се връща съответния стринг, ако ли не - създава се item row (и context row, ако трябва) и се връща стринг от вида: $controller."_".$action."_".$item (т.е., временна визуализация до превод).

Имам отделен интерфейс към администрацията, в който се попълват всички преводи.

По този начин, разработчикът изобщо не се интересува от превод частта - това е отговорност на преводача.

Единственият и много голям минус на този подход е, че за да се "поиска" даден превод и съответно да се създадат сътветните празни записи в базата данни е небходимо run-time кодът да мине през съответния блок. Това е компромисът между свободата на разработчика и пълния превод.

Естествено има начини за преодоляване на този проблем, но тогава доста от целите на подхода се губят.

[VladSun]

хм според мен не е толкова важно самото решение а спецификата.
ако има 50-60 изречения които трябва да се преведат не си заслужава да се ползва база.
ако има големи пасажи от абзаци си заслужава.

Няма по барза база данни от файловата система

По някой път е по-лошо да се раздобяват нещатата от колкото да са на едно място.
Вместо /ланг/<език>/фаил.пхп е по-добре /ланг/<език>.пхп

Трудно бих се съгласил, с което и да е от твоите разсъждения и предложения.

Най-вече, защото решенията за интернационализация се изграждат във framework нивото, т.е. доста по-ниско от предлаганото от теб. Второ, в днешно време уеб приложение (в частност - уеб сайт), което работи без БД едва ли може да има някаква, дори и  достатъчна, функционалност.

[tyuio]

ето едно решение което аз ползвам само дето окончанието в оригинал е  .пхп
http://www.potok.users.space.bg/a/strings.txt
за мен е удобно за всеки език който искам да поддържа, ползвам само гедит и замествам .

[VladSun]

ето едно решение което аз ползвам само дето окончанието в оригинал е  .пхп
http://www.potok.users.space.bg/a/strings.txt
за мен е удобно за всеки език който искам да поддържа, ползвам само гедит и замествам .

Код

GeSHi (PHP):
function sb_language( $page ) {
    global $language, $html_charset, $php_charset, $lang_string;

Код

GeSHi (PHP):
...
   switch ($page) {

Това ми стига за да се откажа да ползвам подобно нещо

[runtime]

В крайна сметка избрах следния вариант

Тъй като сайтчето ми е малко с 6 вътрешни странички, но пък се налага да има база данни заради потребители избрах варианта:

1 - Файл с езика за менюта и съобщения
2 - XML за съдаржанието на 5-те странички + категориите + съдаржанието за 1 флаш.
3 - База данни за потребителските имена и една таблица за статистика

Така и не споменах защо избягвам база данни Ами защото сайтчето е за live stream на уеб камери, не е нищо особено, но пък за идеята си го направих и тъй като трафика ще е по-голям избягвам да товаря сървърчето с излишни заявки, а то горкото не може да се гордее с параметрите си. В случая ще имам само по 1 четене за потребителя и това е.

Но пък определено темата си заслужава за предложенията по сайт с по-голямо съдаржание.
Хубаво е човек да види и други методи за изграждане.
Ако има още какво да се сподели по темата .... ще е хубаво да се каже

[sdr]

Малко късно видях темата но точно по въпроса съм си направил http://sourceforge.net/projects/phplz/ хубавото е че има скриптче за автоматично сканиране и разширяване на файловете с превода. Което не си превел си остава както си го написал ... то си има РЕАДМЕ де..

[VladSun]

Малко късно видях темата но точно по въпроса съм си направил http://sourceforge.net/projects/phplz/ хубавото е че има скриптче за автоматично сканиране и разширяване на файловете с превода. Което не си превел си остава както си го написал ... то си има РЕАДМЕ де..

Критика:
- имаш LFI проблем (http://www.linux-bg.org/forum/index.php?topic=21064.0) с всичките му последици (code execution, XSS и т.н.)
- работиш с глобални променливи (направи си едно класче и ще видиш колко добре ще се наредят нещата);
- зареждаш всеки път пълния превод на сайта (т.е. за всички страници) независимо от това, че ти трябва само превода за една страница/компонент;

[tyuio]

VladSun, не схванах издънката ми, така че моля, разясни ми как ще стане без база данни.
Друго не ползвам, защото и с XML не се разбирам