Хотелось поднять тему многоязычности сайтов, контент которых находится в БД. Я лично реализовывал это следующим образом:
Есть переменная, со значениями ru en и тд, в зависимости от ее значения объявляется константа define('LANGUAGE', '_ru'). При выборке из БД FROM `pages". LANGUAGE ."`.
В принцепе довольно неплохой вариант, мне так кажется, но все же хотелось бы узнать как это реализуют другие...
Спустя 10 минут, 18 секунд (19.07.2010 - 10:55) qpayct написал(а):
есть масса способов. через БД я когда-то тоже пробовал..... это не оправдывается.
ИМХО. самое лучшее - делать шаблоны или массивы.
так же можно переводить при помощи сторонних API таких как google translate. минус этого подхода в том, что перевод получается корявый
ИМХО. самое лучшее - делать шаблоны или массивы.
так же можно переводить при помощи сторонних API таких как google translate. минус этого подхода в том, что перевод получается корявый
Спустя 4 минуты, 18 секунд (19.07.2010 - 11:00) igor717 написал(а):
А по чему это не оправдывается?
Спустя 5 минут, 9 секунд (19.07.2010 - 11:05) qpayct написал(а):
вот опиши структуру своей таблицы языков и как они у тебя выводятся на страницу, я покажу
Спустя 10 минут, 5 секунд (19.07.2010 - 11:15) igor717 написал(а):
две идентичные таблицы вывод осуществляется по url (в таблицах он как id не повторяется)
Спустя 1 минута, 8 секунд (19.07.2010 - 11:16) qpayct написал(а):
таблица для каждого языка отдельно?
Спустя 1 минута, 8 секунд (19.07.2010 - 11:17) igor717 написал(а):
да
Спустя 53 секунды (19.07.2010 - 11:18) igor717 написал(а):
впринце можно конечно и общую, тогда нужно еже одно поле с версией языка
Спустя 3 минуты, 3 секунды (19.07.2010 - 11:21) Basili4 написал(а):
igor717
если в одной таблице.
Я тут вижу проблему что в запросах запутаться можно.
если в одной таблице.
Я тут вижу проблему что в запросах запутаться можно.
Спустя 24 минуты, 38 секунд (19.07.2010 - 11:46) igor717 написал(а):
Basili4, почему запрос делаешь как буд-то и для одного языка, просто добавляешь условие или префикс к таблицы (если таблицы разные).
| Цитата |
| ИМХО. самое лучшее - делать шаблоны или массивы. |
Всмысле, для каждой страничке свой шаблон? А как же динамика?
Спустя 8 минут, 38 секунд (19.07.2010 - 11:54) sergeiss написал(а):
Я лично (пока) не сталкивался с многоязычностью. Но мне кажется очень перспективной идея использовать таблицу, где в одной колонке есть айди, и есть колонки для каждого из языков.
При добавке языка надо будет добавить колонку... Но делаться это будет настолько редко, что не должно быть проблемой
И в отдельной таблице храним краткие имена для языков.
Структура основной таблицы будет выглядеть примерно так:
id_content | content_ru | content_ua | content_en
При формировании запроса указать правильные "суффиксы" для колонок - это не проблема Делается элементарно. Берём букоффки из специальной таблицы, соответствующие выбранному языку, и прибавляем к именам колонок.
При добавке языка надо будет добавить колонку... Но делаться это будет настолько редко, что не должно быть проблемой
И в отдельной таблице храним краткие имена для языков.
Структура основной таблицы будет выглядеть примерно так:
id_content | content_ru | content_ua | content_en
При формировании запроса указать правильные "суффиксы" для колонок - это не проблема
Делается элементарно. Берём букоффки из специальной таблицы, соответствующие выбранному языку, и прибавляем к именам колонок. Спустя 16 минут, 51 секунда (19.07.2010 - 12:11) waldicom написал(а):
| Цитата (sergeiss @ 19.07.2010 - 10:54) |
| Структура основной таблицы будет выглядеть примерно так: id_content | content_ru | content_ua | content_en |
Что будем делать, если надо добавить еще один язык?
Спустя 6 минут, 34 секунды (19.07.2010 - 12:18) igor717 написал(а):
sergeiss, да это вариант тоже неплохой, я о нем думал, вот только придется кучу колонок добавлять имя, контент, ceo (аж 3 колонки), описание и могут быть и другие, а если еще языков много... Не знаю насколько это практично...
Мне кажется, что оптимальней с колонкой lang к примеру, она и будет указывать на принадлежность к языку, а запрос составить тоже не проблема. Но в этом варианте могут быть проблемы при добавлении вложенного контента (придется контент добавлять для каждого языка отдельно).
А если рассмотреть вариант с разными таблицами... Может вот она - лучшая решение?
Даже не знаю...
Мне кажется, что оптимальней с колонкой lang к примеру, она и будет указывать на принадлежность к языку, а запрос составить тоже не проблема. Но в этом варианте могут быть проблемы при добавлении вложенного контента (придется контент добавлять для каждого языка отдельно).
А если рассмотреть вариант с разными таблицами... Может вот она - лучшая решение?
Даже не знаю...
Спустя 7 минут, 13 секунд (19.07.2010 - 12:25) sergeiss написал(а):
| Цитата (waldicom @ 19.07.2010 - 13:11) |
| Что будем делать, если надо добавить еще один язык? |
| Цитата (sergeiss @ 19.07.2010 - 12:54) |
| При добавке языка надо будет добавить колонку... Но делаться это будет настолько редко, что не должно быть проблемой |
Вряд ли планируется каждый день добавлять/удалять языки.
Спустя 3 минуты, 53 секунды (19.07.2010 - 12:29) inpost написал(а):
sergeiss я так и делал многоязычность =)
waldicom Тогда уже появляется куда интереснее вопросы, а можно ли добавлять колонки с полями для уже созданной таблицы, к примеру сontent_ge, и т.д.??
waldicom Тогда уже появляется куда интереснее вопросы, а можно ли добавлять колонки с полями для уже созданной таблицы, к примеру сontent_ge, и т.д.??
Спустя 48 секунд (19.07.2010 - 12:30) igor717 написал(а):
А вообще если подумать над вариантом sergeiss то можно даже такую штуку реализовать на случай отсутствия контента нужного языка: Проверку, если поле (к примеру content_en) пустое, то выводи дефолтное...
Спустя 15 минут, 17 секунд (19.07.2010 - 12:45) igor717 написал(а):
sergeiss, извините не внимательно прочел, я подумал что будет одна общая таблица (где будет все), а Ваш вариант отличается только реализацией от моего второго
| Цитата |
| Мне кажется, что оптимальней с колонкой lang к примеру, она и будет указывать на принадлежность к языку, а запрос составить тоже не проблема. Но в этом варианте могут быть проблемы при добавлении вложенного контента (придется контент добавлять для каждого языка отдельно). |
этот даже проще в реализации...
Спустя 1 час, 1 минута, 17 секунд (19.07.2010 - 13:46) qpayct написал(а):
| Цитата (igor717 @ 19.07.2010 - 10:46) | ||
Всмысле, для каждой страничке свой шаблон? А как же динамика? |
можно по разному. шаблоны для того и придуманы, чтоб без выгрузки из БД и распределения что куда, всё красиво, а главное быстро и динамично комплектовать. работать с таким сайтом будет просто удовольствие: вместо того, чтобы заходить каждый раз и рыскать по бд берёшь и заходишь в language/ru/menu.tpl и т.п.
для примера:
делаешь одну страницу шаблон меню допустим, в неё вставляешь переменные пхп содержащие перевод - динамично, а можно и для каждого языка сделать отдельную страницу. в любом случае намного удобней и быстрей работать чем с таблицами, которых может быть и больше 50 штук в итоге
всё зависит в первую очередь от того, что вообще надо и зачем. так как ты не даёшь какой либо информации остаётся только тыкать пальцем в небо
Спустя 45 минут, 8 секунд (19.07.2010 - 14:32) igor717 написал(а):
| Цитата |
| делаешь одну страницу шаблон меню допустим, в неё вставляешь переменные пхп содержащие перевод - динамично, а можно и для каждого языка сделать отдельную страницу. в любом случае намного удобней и быстрей работать чем с таблицами, которых может быть и больше 50 штук в итоге |
Понятно что 100% контента сайта держать в базе не стоит, но некоторые части страниц все же должны находится в БД без этого никуда... Что-то можно и даже нужно определить и переменными пхп в шаблонах.
| Цитата |
| всё зависит в первую очередь от того, что вообще надо и зачем. так как ты не даёшь какой либо информации остаётся только тыкать пальцем в небо |
Конкретно, так конкретно мне ничего и не надо, просто хотел узнать как кто реализует многоязычность, поучится у других, улучшить то что есть. Цель: обучение, повышение квалификации или что-то в этом роде
Спустя 5 минут, 55 секунд (19.07.2010 - 14:37) Adil написал(а):
Зачем отдельная таблица, для каждого языка?
Можно сделать таблицу langs. В котором id,name
И langvars. В котором id,lang_id,var
И все. Делаем некий класс или функцию, который по id и lang_id выбирает слово.
$lang->word(133, "ru");
Легко из админки добавлять языки и слова.
Можно сделать таблицу langs. В котором id,name
И langvars. В котором id,lang_id,var
И все. Делаем некий класс или функцию, который по id и lang_id выбирает слово.
$lang->word(133, "ru");
Легко из админки добавлять языки и слова.
Спустя 6 минут, 40 секунд (19.07.2010 - 14:44) igor717 написал(а):
Adil, вот кстате про это и предыдущий пост. За отдельными словами лазить в БД по мне так не стоит, лучше их задавать в языковых файлах переменными или константами. Ну а конент все же по мне лучше брать так (на отдельные таблицы разбивать не надо - запросы объединять не надо):
| Цитата |
| Мне кажется, что оптимальней с колонкой lang к примеру, она и будет указывать на принадлежность к языку, а запрос составить тоже не проблема. |
Это одна таблица
Спустя 4 минуты, 12 секунд (19.07.2010 - 14:48) Wird_34 написал(а):
Что-то я не видел скриптов с многоязычностью реализованной при помощи базы данных, да и мне кажется это не целесообразным, плюс этот способ мне кажется неэффективным. Чтобы добавить новый язык нужно будет или отдельно скрипт для этого писать или лезть в базу данных, т. е. человек в этом не разбирающийся сделать не сможет, или какой-то модуль к сайту делать для перевода, что опять таки не целесообразно. В общем одни минусы не вижу смысла в этом.
Спустя 33 минуты, 23 секунды (19.07.2010 - 15:22) sergeiss написал(а):
| Цитата (Wird_34 @ 19.07.2010 - 15:48) |
| Чтобы добавить новый язык нужно будет или отдельно скрипт для этого писать или лезть в базу данных |
Интересная мысль... А если делать такую фишку БЕЗ БД, то что, не надо никаких специальных финтифлюшек делать в коде, что было лёгкое переключение между языками, добавление/удаление языков?
Спустя 8 минут, 27 секунд (19.07.2010 - 15:30) Wird_34 написал(а):
В случае со сценариями, а не базой данных, код нужен будет только для их обнаружения и добавления, если не найдено значит нет. А код для переключения языка конечно писать придется, я об этом ничего не говорил.
Спустя 4 минуты, 20 секунд (19.07.2010 - 15:34) Семён написал(а):
| Цитата (sergeiss @ 19.07.2010 - 12:54) |
| Я лично (пока) не сталкивался с многоязычностью. Но мне кажется очень перспективной идея использовать таблицу, где в одной колонке есть айди, и есть колонки для каждого из языков. При добавке языка надо будет добавить колонку... Но делаться это будет настолько редко, что не должно быть проблемой И в отдельной таблице храним краткие имена для языков. Структура основной таблицы будет выглядеть примерно так: id_content | content_ru | content_ua | content_en При формировании запроса указать правильные "суффиксы" для колонок - это не проблема Делается элементарно. Берём букоффки из специальной таблицы, соответствующие выбранному языку, и прибавляем к именам колонок. |
Солидарен с данной реализацией.