1 июня 2009 в 8:08
Много страниц этого форума поcвящено переводам drupal и проблемам с ними. В ходе работы над drupal 7 наткнулся на довольно интересное замечание-правку, а именно добавление контекста к переводимой строке. После доведения её до рабочего вида, решил собрать мнения и пожелания русско-говорящего сообщества.
- Итак, чего же собственно Вас не устраивает в текущем подходе к переводу строк?
- Чего хотелось бы изменить?
- Какие наработки можно довести до включения в ядро новой версии?
Этот список можно дополнять, большая просьба высказаться всем, кому небезразлична судьба переводов!
Разработчики, обратите внимание на указанную выше доработку!
Лично мне кажется, что стоит сделать систему переводов подменяемой, для этого нужно всего лишь за оставшиеся 3 месяца протолкнуть совместно патч в ядро.
Пользователи, высказывайте ваши пожелания!
Комментарии
Т.е. каждую строку, несмотря на идентичность другой (из другого места), можно будет перевести отдельно?
Опрос закрыт
Хотелось бы, чтобы по умолчанию использовался единый стандартный перевод для фраз, но была возможность иметь уникальный (по контексту).
Действительно очень нехватает функций перевода по контексту.
Именно возможность перевода по контексту и добавляется!
PS: Опрос вроде бы включил.
Так же хочу напомнить, что по умолчанию есть возможность перекрывать хранилище перевода заменив стандартный модуль locale на свой (по сути переопределив функцию [ru-api=locale]locale()[/ru-api])
А примеры реализации имеются?
Примеров нет, так пока не возникало необходимости, но смысл прост:
создаем свой модуль, который содержит функцию [ru-api=locale]locale()[/ru-api], отключаем тот который в ядре - соответсвенно все запросы на перевод из [ru-api=t]t()[/ru-api] будут приходить в нужное нам место.
Классно. Вспоминаю свой пост почти годовой давности на drupal.org. Что характерно ни одного ответа на него не получил.
http://drupal.org/node/300978
Причём по-моему я предложил более удачный вариант, потому что он не требует указания специального контекста в большинстве случаев, потому что сам автоматически берёт нужный контекст, основываясь на имени файла, из которого произведён вызов функции t().
Посмотрел я этот пост. Такие предложения не имеет смысла обсуждать на форуме, там в основном поддержка, а не разработка.
Самый эффективный путь - выдать issue в проект (очень желательно с патчем) и, например, на irc обсудить с мэйнтейнером.
Мое предложение не пихать кириллицу в урлы для полей профиля тоже на доторге замолчали
Значит, не так надо усилиия прилагать.
Почему же замолчали - там даже 2 варианта решения привели! Чем не понравилось решение с японским языком? у них те же проблемы
А как надо? Давно интересуюсь, что же и как надо сделать, чтобы хотя бы заметили, что написал.
Обсуждение рискует сьехать в оффтоп, но drupal.org у меня производит впечатление некой закрытой секты, куда допущен узкий круг посвящённых, а остальные идите лесом.
На org довольно много разных предложений.
В модулях - если автор активный гораздо проще что-то полезное внедрить.
За ядром не так много народа следит. Все предложения отслеживать и испытывать ни у кого нет желания и физической возможности. Можно пробовать организовывать небольшие флеш-мобы, для джействительно полезных вещей. Проверенно - помогает
Я не говорю про внедрение - это уже предел мечтаний. Но хотя бы обсудить! Хотя бы написать - мол, мужик, ты бредишь и обосновать почему! А не так, что написал и тишина!
На самом деле ядро очень большое и, объективно, весь его функционал мало кто знает! Для этого в корне инсталяции лежит MAINTAINERS.txt в котором написано, кто и за что отвечает.
Подход к включению в ядро довольно прост - если кроме запросившего на это issue никто не откликнулся, логично считать, что это никому не нужно и не стоит тратить время на даже на рассмотрение.
Вообще, Василий прав, нужно отдельную ветку на форуме сделать по проталкиванию разных проблем.
По опыту: из ~8 подобных случаев 6 были изменены и доработаны.
побольше бы правил, принципов перевода, а то русский язык слишком скуп на перевод спецлексики
У Вас есть идеи по добавлению "правил" и принципов?
Русский язык как раз вовсе не скуп... наоборот, головы забиты слишком большим количеством синонимов и оттенков.
В принципе, нужная штука. Кнопки "просмотреть" и "изменить" в профиле совсем не в тему, да и "search" можно будет наконец нормально переводить, это в английском существительное и глагол одинаково пишутся, а нам надо писать в названии "Поиск", но в форме на кнопке "Найти".
Только вот реализация, это же сколько строк надо будет перелопатить, чтобы добавить этот контекст везде... Надо что-то более автоматизированное.
Или, как писали выши контекст зависит от файла и строк, или привязать к названию форму, адресу страницы и пр.
Не сильно в тему, но было бы неплохо иметь возможность указывать в locale(), в какую группу переводов этот перевод должен быть занесен.
Вообще-то, очень даже в тему... я вот так и не понял, как эти группы вообще используются...
По идее контекста вполне должно хватить, но группа перевода используется по крайней мере для поиска строк
Проталкивание решений силами русскоязычного сообщества - идея на миллион. Я руками и ногами за!!!
Зачем это нужно:
* На моей памяти был случай, когда в Drupal 4.7(в отличие от 4.6) перестали работать формы множественного числа для переводов. Разработчики обратили на это внимание и исправили только в версии 4.7.2( http://www.drupal.ru/node/1630 ).
* По собственному опыту: запостил на drupal.org свою модификацию одного модуля( http://drupal.org/node/203951 ), так maintainer ответил только спустя 2 месяца, когда у меня уже не было ни времени, ни желания заниматься дальнейшей модификацией этого модуля.
Низкая скорость работы модуля локализации - самый большой его минус ИМХО.
Идея витает давно, но пока нет времени-сил довести до ума.
На www.drupaler.ru уже есть вписки модулей, даже с небольшим описанием каждого (спасибо Василию), теперь хорошо бы к каждому из них прикруть issues и настроить оповещения на почту - таким образом можно будет собирать отзывы и пожелания о конкретных модулях, а разработчики смогут на родном языке общаться и вносить изменения, которые потом можно будет проталкивать в официальные ветки или плодить форки.
Другую группу стоит заводить, если ты хочешь хранить в таблицах локали переводы каких-то пользовательских данных (например, так нужно было бы сделать в первой версии api.drupal.ru, но тогда я еще об этом не знал, и как следствие, сейчас 4K сорцов апи в таблице локали перемешано с сорцами интерфейса). Еще одна полезность — ты можешь отдельно экспортировать po-файлы разных групп.
Реализация, на самом деле, элементарная — добавить один параметр в функцию и в запрос вместо 'default'. Странно, чего еще так не сделали. Надо бы глянуть в i18n, там есть функция tt(), в которой уже сделано что-то похожее.
По хорошему нужно ворваться в результаты i18n спринта, там очень много было озвучено идей, вот только, боюсь, с реализацией как обычно затянется, так как код писать не языком трепать...
tt() таки намного умнее, но если уже в ядре есть возможность работать с разными группами - почему бы её не довести до ума?
Следует писать не поучаВствую, а - поучаствую.
Спасибо, поправил.
У меня вот была в своё время идея избавится от слов таксономия, словарь и термин, заменив их более понятными словами: категоризатор, группа категорий, категория. Однако термин категория уже занят в других местах, например применительно к новостям и формам обратной связи (контактам) - будет путаница.
Очень хотелось местами перевести Enabled не как Включено, а как Разрешено, не говоря уже о родовых окончаниях, которые к сожалению сейчас никак не привинтить: включен, включена и т.д.
Тяжелей всех Ґабору, в его языке 18 падежей
Не, не 18, а 22
Простите за обтоп, а что за язык такой??? Венгерский? (теперь мне стало понятно, почему идею он взялся за переводы и многоязычие...)
Да, magyar lengyel
Ну вот и состоялось - патч прошел в ядро и теперь нужно пересмотреть вхождения строк и сделать ядро более "переводимым"
PS: так же нужно переработать документацию с учетом данного изменения.
Поздравляю!
А можно поподробней - в чём суть патча, что он даёт?
В настоящее время, сервер переводов поддерживает локальные клиенты. (Возможно отправлять переводы строк не сервер, при работе со своей локальной копией).
Настройка простая, "подробная инструкция" приложена.
Не совсем понятно.
Получается у каждого пользователя своя локальная копия перевода на сервере локализации? Или нет и перевод на сервере локализации один? Если перевод один, то что произойдёт при попытке исправить уже существующий перевод?
Видимо инструкция нуждается в дополнительных пояснениях, потому что ответов на эти вопросы там нет.
Перевод один. При наличии соответствующих прав на сервере переводов при попытке исправить перевод, он будет заменен вашим переводом строки.
Ясно. Следующий вопрос, на который мне так никто и не ответил ранее.
Что с авторскими правами на перевод?
Дело даже не в том, чтобы как-то выделится и поставить своё имя в ряд с прочими светилами (хотя а почему бы нет, если человек трудится, то пусть хотя бы признание получает, если не деньги), а в том, чтобы потенциально избежать возможных претензий в незаконном использовании чужого авторского материала. Допустим кто-то недобросовестный, выполнив множество переводов и загрузив их на сервер скажет - давайте бабки мне все, кто моими переводами пользуется - ведь я вам таких прав не давал! А кроме того, вы (даже согласно GPL и GFDL) не упоминаете моего авторства!
Ещё одна проблема - допустим я захотел убедить переводчика, что нашёл более правильный термин или нашёл ошибку в переводе. Прав на правку у меня нет - кому писать?
У меня на сервере оговорена в футере лицензия по которой распространяются переводы. Думаю, Василию следует тоже это сделать для предотвращения подобных вопросов. Недобросовесный человек не будет выполнять много переводов и загружать их на сервер, контент которого на GNU GPL распространяется.
Каким образом будем указывать ваше авторство? Работа в большей части коллективная и результат принадлежит сообществу, а не конкретному автору.По-моему вполне справедливо. Может быть под каждой переведеной строкой подписывать ваше авторство,а? Чтобы все видели потом. Как такая идея?
Нашел более правильный термин - пиши переводчику с правами.
Про копирайте и CC есть ветка давайте эти вопросы всё же туда...
- я с удовольствием сделаю это, ибо это коллективный труд. Но я не знаю форму в которой это можно сделать(заявить) в России. Бардак(дороги и дураки...)Я уже склоняюсь сделать как Дриса на drupal.org: выставить явно копирайт внизу сайта, дабы не возникало лишних инцидентов. : имея аккаунт на сервере переводов - отправьте запрос на вступление в соответствующую группу (того языка, на который хотите переводить). У вас появится соответствующий интерфейс для правки. Так же вы сможете отправлять переводы (автоматически), исправляя что-то у себя на сайте локальным клиентом.
Все получаемые с сервера переводы не содержат упоминания о копирайтах.
Пока только: http://drupaler.ru/translate/heroes содержит всех, кто внес свой вклад.
А модуль который будет позволять загружать переводы к вам на сервер будет показывать и заставлять акцептовать текст лицензии? Или просто при регистрации пользователя ему будет показана лицензия и только в случае её акцептования ему будет дозволено работать с сервером?
Ох уж мне эти переводы на личность
Работа безусловно коллективная, спору нет. Но вот давайте возьмём сам Drupal. Работа тоже коллективная, но что характерно каждый модуль имеет своего автора или авторов не так ли?
Нет безусловно, подписывать каждую строчку автором - это дурь несусветная, но добавлять автора перевода в заголовок .po файла (если такое кто захочет угрузить) а также хранить историю кто чего и когда добавил/изменил было бы очень даже разумно. В том же CVS репозитория кода Drupal можно найти кто автор тех или иных патчей и в итоге понять кто же писал код.
Мдя. Тоже выход конечно. Хотя "кто костюмчик пошил" всё-равно не понять.
Для локализации есть 2 модуля. Сервер и клиент. Оба вы можете использовать у себя.
1) На http://drupale.ru установлен сервер, в который собраны все существующие в рунете переводы модулей на нескольких языках.
Север позволяет при наличии определённых прав(я писал о них выше) получить доступ к добавлению/изменению существующих и новых переводов.
2) Локальный клиент позволяет переводить строки в вашей локальной установке.
3) Сейчас есть возможность удобно делиться данными со всеми (отправляя переводы на общий сервер). Ничего ни где акцептировать не нужно.
Сервер переводов хранит информацию об авторе каждой переведённой строки.
Студия Razgonka.ru был противником обезличенных переводов. Ничего не предложил и его вклад, репутация и польза для сообщество в этом вопросе в итоге = 0.
По поводу авторства - любые предложения приветствуются. Я не знаю как тут лучше поступить и сделать.
Т.е. если ничего и нигде акцептовать не нужно, получается что человек загружающий переводы может оказаться не в курсе условий лицензии на использование его труда или несогласным с этой лицензией? Если это так, то вот вам и потенциально возможные преценденты для претензий в будущем!
По поводу авторства.
1. При получении .po файла с сервера переводов в нём должна быть информация обо всех участниках, которые занимались переводом строк в этом .po файле
2. При получении перевода клиентом, также неплохо бы выводить список переводчиков, которые занимались переводом с указанием ссылки, где можно получить этот список снова с указанием способа связи с автором (для целей отсылки ошибок авторам для последующего исправления).
3. Либо при получении прав на запись к серверу локализации, либо при загрузке переведённых строк на сервер локализации, пользователю должен выдаваться текст лицензии (достаточно одного раза), который должен им акцептоваться.
И ещё. Совершенно не понимаю как будут решаться конфликты по терминам между двумя переводчиками, если оба имеют права на запись. Один пишет одно, другой следом правит другое, первый следом правит исправленное обратно и т.д.
http://drupal.org/node/224333 # locale_context вот Габр описал нововведение по поводу контекста.
А по поводу сервера переводов, давай-те не засорять ветку!!! для этого есть другие темы и, собственно, форум на сервере переводов.
locale_context - весьма нужная и полезная штука - стопудово! В семёрке я чую локализация интерфейса будет на более высоком уровне.
Что касается обсуждения сервера переводов, то я не против отдельной ветки, но здесь, а не там, потому что там мне регистрится откровенно влом. Модераторы, пожалуйста, отделите, если можно тему.
Обновился севрер локализации http://drupal.org/cvs?commit=239634
Теперь в него включена поддержка контекста, пора распихивать контекст по коду.
поднимаю тему, ибо нужно успеть до заморозки строк это дело сделать! Иначе русский перевод мы получим с очень большим опозданием и опять с косяками...
Это относится не только к контексту, но и к группам перевода
Также висит открытым вопрос контекста для JS http://drupal.org/node/488496