Мысли по поводу i18n
Прислано: seaji
вт, 27/04/2010 - 13:00
Хочу посоветоваться с народом.
Вот мне пришла в говову мысль, что система переводов материалов организована в принципе не верно. В частности это касается модуля i18n.
В данный момент, когда вы создаете перевод, вы фактически создаете новую ноду.
Я столкнулся с такой проблемой. У меня есть фильмы, за них можно голосовать. Но голоса за русскую версию и за английскую версию считаются отдельно т.к. это разные ноды, а нужно, что бы они считались вместе.
Было бы логичнее не создавать новую ноду, а создавать ноду с тем же ID но с другой меткой языка. И полям то же назначать метку языка.
Я думаю, что в этом случае можно было бы избежать многих проблем, которые возникают при использовании i18n.
Что вы про это думаете?
- seaji's blog
- Для комментирования войдите или зарегистрируйтесь
Думаю, что то, что вы описали вполне логично.
- Для комментирования войдите или зарегистрируйтесь
А как по поводу реализации? Есть такое? Кто нибудь знает?
- Для комментирования войдите или зарегистрируйтесь
У меня такое предчувствие, что проще в CCK сделать разные поля ru|en а потом через препроцессинг прогонять ноду и там уже подставлять нужные поля в зависимости от языка.
- Для комментирования войдите или зарегистрируйтесь
Я столкнулся с такой проблемой. У меня есть фильмы, за них можно голосовать. Но голоса за русскую версию и за английскую версию считаются отдельно т.к. это разные ноды, а нужно, что бы они считались вместе.
Не знаю Вашу "голосовалку", но может проще посмотреть в сторону - есть ли у неё какие-то хуки чтоб влезть в процесс, вычислить ноду с переводом и задублировать голос и для неё.
Как по мне это проще будет чем переделать механизм переводов.
- Для комментирования войдите или зарегистрируйтесь
Логично, но не совсем хорошо в плане производительности.Ведь по сути вовсе необязательно на одном языке показывать то что есть на другом, да и не всегда нужен именно перевод.
Однако иногда бывают задачи о голосовании с точностью до наоборот т.е. раздельное голосование и вот тут вы получите на выходе (при условии 1 нода + ССК по языкам) гораздо больше кодинга.
У меня к примеру была тоже задача организовать голосование за фирму пользователя на нескольких языках, я решал эту проблему следующим образом:
1. Создал глобальную ноду типа global_firm независимую от языка т.е. показывается везде
2. В ней есть ССК поля глобальных настроек которые рядовому пользователю не нужны т.е. не отображаются (поскольку у меня еще и мультисайтинг).
3. Вывожу в теле этой ноды информацию о фирме в зависимости от global $languages;
на выходе по факту юзер голосует за 1 глобальную ноду фирма, а отображаемый контент это независимое.
- Для комментирования войдите или зарегистрируйтесь
Не знаю Вашу "голосовалку"
голосовалка обычная Fivestar
на выходе по факту юзер голосует за 1 глобальную ноду
Тоже интересная мысль. Сделать глобальную ноду, а из нее сделать референс на английскую и руссую версии. Исчезает необходимость создания русских и английских полей. Но повышается количество типов материалов.
- Для комментирования войдите или зарегистрируйтесь
Кстати проблема не только в голосовалке.
Еще нужно следить за количеством просмотров, которое то же будет отличаться для русской и английской версии.
- Для комментирования войдите или зарегистрируйтесь
Исчезает необходимость создания русских и английских полей. Но повышается количество типов материалов.
Увеличение на 1 таблицу в БД :) в моем случае.
Вот с просмотрами уже сложнее в плане разделения на русские и английские у меня было в задаче считать общее количество, как сами понимаете задача решилась сама собой :).
Если придет какая мысль кроме глобального самописа, то озвучу.
- Для комментирования войдите или зарегистрируйтесь
По-моему это бага голосовалки, а не i18n, т.к. механизм переводов стандартен, и пора бы уже учитывать tid в подсчетах. Это проблема почти всех голосовалок друпала.
- Для комментирования войдите или зарегистрируйтесь
Комментарии