Мультиязычность.

[vbnm]

способом добавления пакета Ру в папку Языки и доп правкой файлов Индекс, либо base.php
нужного функцианала не добился.
руссифицируется админка, а страницы написанные на англ версии остаются прежними...
здесь опять всплывает тема клона постраничного, что добавляет лишней работы...но наверное без этого пока ни как..
поищу еще решения

[vbnm]

<center><a
href="$HOME_PAGE_LINK$" target="_blank"><img border="0"
align="absmiddle"
src="http://im6-tub.yandex.net/i?id=54728023-07"></a></center><center><a
href="http://translate.google.com.ua/translate?hl=ru&sl=ru&tl=en&u=$HOME_PAGE_LINK$"
target="_blank"><img border="0" align="absmiddle"
src="http://im7-tub.yandex.net/i?id=90962689-07"></a></center><center><a
href="http://translate.google.com.ua/translate?hl=ru&sl=ru&tl=de&u=$HOME_PAGE_LINK$"
target="_blank"><img border="0" align="absmiddle"
src="http://im8-tub.yandex.net/i?id=66815353-04"></a></center>

[Count_Raven]

Вот это последнее - что это было?

Вы Google Translate решили делать переводы страниц?

Функционал он-лайн переводчика можно внедрить, но это, на мой взгляд - маразм. Так как это машинный перевод.

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

[cmsservice]

Судя по тому, как двигаются технологии у Google, я не удивлюсь если через 3-5 лет перевод у них будет слабо отличим от сделанного простым переводчиком человеком.

2vbnm: Если нужен гугловски переводчик, то в Marketplace есть соответствующее расширение.

[vbnm]

Вы Google Translate решили делать переводы страниц?

я подумал о том, как бы его включить в модуль мультиязычности, комбаин такой чтоль
таким образом можно разгрузить сайт, БД и не потерять возможного пользователя не из вашей яз группы.
ну..кто его знает, может таблица в БД с мультиком полетит и сайт на время останется без ин яза, а тут кнопочка

то в Marketplace есть соответствующее расширение.

Спасибо за подсказку.
и Еще, есть на русском детальное объяснение, как разрабатываются модули под Конкрете5?
Хотя бы список стандартных файлов и их функционал?
Так, пока возился с модулями заметил, что набор почти везде один и тот же, а нек файлы просто близнецы.

Что удивило, не смог поставить блок Пей-Пола на локале, ни в рус, ни в англ версии сайта качал его с основного.

[vbnm]

Пожалуйста зарегистрируйтесь, чтобы увидеть ссылку

как оказалось делал все так, как описано тут
результат озвучен выше.
попробую скачать и установить другую локализацию, посмотрим))

[vbnm]

поставил франц локаль(яз. пакет)
брал отсель:

Пожалуйста зарегистрируйтесь, чтобы увидеть ссылку

та же самая ситуация, админка вся в шелках)))
страницы переводится не хотят, как и при русской локале (уст русспакета)
указывал через фаил Сайт.пхп
строка:
<?php
define("LOCALE", 'fr_FR');

[vbnm]

угум, вроде разобрался в чем причина, но возможно ошибаюсь.
1 для полного функционала Геттекста необходимо, чтобы информация (т.е текст который нужно перевести) находилась в папке сайта, а не только в таблице БД.
2 у меня есть возможный баг в русской версии,- при попытке перехода в ней на иной язык часть админки не переводится, по причине того, что информация левой колонки скорее всего находится только на стороне сервера в БД.
Это скорей всего идет с того времени, когда делали полный перевод, что-то вырезали, а обратно поставить забыли.
3 Карта сайта по умоляанию, а так же все основные названия страниц так же прямиком сохранятся в БД без дублирования в папках сайта. Это конечно экономит место и прибавляет скорости, но при этом гробится идея использования яз библиотек посредством Геттекст для них.
Получается так, если даже вы поменяли локаль, админка с исходника, т.е англ версия вся спокойно переходит на другой яз, но при этом на стороне отображения страницы сайта названия страниц, разделов, карта сайта,- остаются в прежнем виде.
Home, Blog, Search у меня к примеру не переводятся (но при этом слова находятся в библиотеке),- возможно это огрех локального сервера, возможно у него не хватает каких-то расширений, поэтому могу только попросить тех у кого хост-онлайн проверить это. (установите локаль на другом языке и посмотрите, как реагирует КАРТА САЙТА)
Если так, то понадобиться модуль, котрый бы позволял выводить карту сайта, разделы, страницы в файл на стороне сайта, чтобы потом можно было использовать Геттекст. К этому модулю необходимо сразу приплетать модуль первода на иной яз, для добавления в яз базу. нестандартных названй страниц, разделов, можно конечно просто ограничится транслитом на первое время)))
Потому что в исходной версии эта функция отсутсвует.
или же нужна функция, чтобы научить Геттекст переводить инфу взятую непосредственно с БД и которая отсутсвует на стороне папок сайта, но он же не работает с кешем, а только реагирует на выражениями прописанными и взятыми в скобки на стороне сайта т.е файловой системой, а не таблицами БД.
нужно еще посмотреть инфу по Геттексту.

[cmsservice]

Сударь... по ходу вы загнались. Карта сайта (названия страниц) это часть контента, оно и не должно переводиться языковыми файлами, они для другого предназначены. И ни в одной CMS я этого не видел. Технология созания мультиязычных сайтов подразумевает два слоя:
1. Слой отвечающий за перевод статичных строк в системе - за это везде отвечают языковые файлы.
2. Слой отвечающий за языковые версии контента - обычно это либо специальный компонент, который внедряется в систему на уровне класса отвечающего за доступ к базе данных (по сути подменяет его собой) и на этапе запросов подсовывает ответ на нужном языке, если таковой был внесен администраторами сайта (т.е. сам он там ниоткуда не появляется). Другой, часто применяемый, способ реализации этого слоя - языковые версии страница основного сайта (в частности у нас на двух проектах это реализовано). Как показывает опыт это самый правильный способ. Причина в том, что практически всегда языковые версии сайта различаются по набору контента и, часто, структуре (присмотритесь к языковым версиям сайтов крупных корпораций).

[vbnm]

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

И ни в одной CMS я этого не видел.

посмотрите Друпал, Буддипресс на Вордпрессе, Moodle и ТиКиВИКи. я говорю о коробочных версиях.
где система локалзации уже прошита, либо настроена так, что пользователю не приходится лазить в БД, иль править локальные файлы сайта, а просто иногда достаточно установить плагин, если он не входит в сборку по умолчанию

Мудли.JPG

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

[vbnm]

что вы видите нестандартного в словах: Главная, Блог, Поиск. Карта сайта, Меню, что они заслуживают отнесения к внутреннему уникальному контенту?
Их по идее можно включить и выключить, но не относить к уникальным областям.
Значит после локализации сайта, нам еще нужно устанавливать локализацию блоков отвечающих за вышеперечисленное, это большой гемор с которым бьются на основном сайте, судя по тому, что успел прочесть..
так что легче сделать так, чтобы меню пользователя и карта сайта вбирающе в себя по сути набор блоков и их название, могли стандартно локализироваться на большинстве языков через геттекст. об этом и речь.
а новые блоки, плагины и тд и тп, их отображение на сайте, пришпилить к системе перевода посредством гугл в зависисмости от выбора яз группы пользователя, но только НОВЫЕ, которые админ, или сами разработчики не успели прописать в папках локализации, котрые в свою очередь могли бы переводится посредством функции геттекст.
хотя я думаю, что разработчики конкрете к этому уже идут.

[cmsservice]

что вы видите нестандартного в словах: Главная, Блог, Поиск. Карта сайта, Меню, что они заслуживают отнесения к внутреннему уникальному контенту?

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

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

Там бьются с тем, что не все блоки содерать локализацию, кроме того, не все блоки поддерживают локализацию на уровне кода. Но это проблема разработчиков блоков.

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

Не легче, это будет означать потерю гибкости системы и на это никто не пойдет.

хотя я думаю, что разработчики конкрете к этому уже идут.

Не думаю.

[cmsservice]

посмотрите Друпал, Буддипресс на Вордпрессе, Moodle и ТиКиВИКи. я говорю о коробочных версиях.
...skipped...

Вот это как раз и есть Слой №1.
Еще нужен Слой №2

Поймите Вы наконец, что добавив языковые файлы Вы не переведете сайт на другой язык, а только статику. Контент останется тем же, каким и был.

[vbnm]

"Контент останется тем же, каким и был."

это понятно, что контент останется прежним, его переводить и не требуется средствами сайта, для этого есть иные средства.
но..
эту часть, что можно отнести к меню, карте и названию страницы пользователя:

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

нужно попробоват прогнать через локалзацию средствами геттекст.

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

Слой №2

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

давайте так разобъем понятия
внутренняя часть административная это слой1
уникальный контент, статьи, фото, изображения, ...это слой2
и..
слой 3, это меню, карта, и название страниц, которые вкупе и представляют меню, карту.

слой1 у нас уже спокойно локализуется, правда в русской сборке у меня по-прежнему баг админ панели,- левая калонка остается на русском при любой локализации
слой2 мы вообще не трогаем
нам нужно сосредоточится на слое3

[Count_Raven]

давайте так разобъем понятия
внутренняя часть административная это слой1
уникальный контент, статьи, фото, изображения, ...это слой2
и..
слой 3, это меню, карта, и название страниц, которые вкупе и представляют меню, карту.

слой1 у нас уже спокойно локализуется, правда в русской сборке у меня по-прежнему баг админ панели,- левая калонка остается на русском при любой локализации
слой2 мы вообще не трогаем
нам нужно сосредоточится на слое3

Объясню по пунктам:
1. Левая колонка всегда останется на том языке, на котором была система при установке.
Почему? Объясняю. Левая колонка - это не какие-то зашитые в систему моменты. Сама админка также состоит из страниц, только они называются "Single Pages". Эти страницы можно добавлять, каждый пакет при установке может создать себе в этой левой колонке кнопочку или много для своих административных нужд. Создаются такие страницы при помощи такой конструкции в контроллере какого-нить нашего пакета:

Код: Выделить всё

Loader::model('single_page');
$my_page = SinglePage::add('dashboard/my_page', $pkg);
$my_page->update(array('cName' => 'Моя страница', 'cDescription'=>'Тут можно тыкать в небо.'));

После этого в левой колонке в админке появится кнопка "Моя страница" с подписью "Тут можно тыкать в небо". Вся эта информация записывается в Базу Данных и при смене языка эти названия никак не изменятся. Потому, что сама админка - это и есть в данном контексте, как вы выразились "слой 2". Это уникальный контент, который динамически добавляется в базу. Хотите его изменить, тогда необходимо будет при смене языка передобавлять все эти "Single Pages", а контроллер должен уже иметь пару изменений для gettext:

Код: Выделить всё

$my_page->update(array('cName' => t('Моя страница'), 'cDescription'=>t('Тут можно тыкать в небо.')));

Есть и еще один вариант (не очень качественный с точки зрения лишних запросов к базе данных" - в самих контроллерах всех "Single Pages" добавить в метод view() или в on_start() обновление названия и описания страницы, они в зависимости от действующего языка соответственно изменятся. Но это при каждом просмотре страницы будет выполняться запрос к базе данных.

2.

слой 3, это меню, карта, и название страниц, которые вкупе и представляют меню, карту.

Не-не-не! Вы не понимаете как тут работает система. Эти вещи не должны переводиться автоматически, это тот же "слой 2". Это контент. Тут мудрить не надо, не тем путем идем, товарищи!

3. Да, в Drupal неплохо для локализации сделано.