Улучшаем систему переводов

Главные вкладки

Аватар пользователя andypost@drupal.org andypost@drupal.org 1 июня 2009 в 8:08

Много страниц этого форума поcвящено переводам drupal и проблемам с ними. В ходе работы над drupal 7 наткнулся на довольно интересное замечание-правку, а именно добавление контекста к переводимой строке. После доведения её до рабочего вида, решил собрать мнения и пожелания русско-говорящего сообщества.

  • Итак, чего же собственно Вас не устраивает в текущем подходе к переводу строк?
  • Чего хотелось бы изменить?
  • Какие наработки можно довести до включения в ядро новой версии?

Этот список можно дополнять, большая просьба высказаться всем, кому небезразлична судьба переводов!

Разработчики, обратите внимание на указанную выше доработку!

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

Пользователи, высказывайте ваши пожелания!

Комментарии

Аватар пользователя PVasili PVasili 1 июня 2009 в 9:04

Опрос закрыт Sad
Хотелось бы, чтобы по умолчанию использовался единый стандартный перевод для фраз, но была возможность иметь уникальный (по контексту).

Аватар пользователя andypost@drupal.org andypost@drupal.org 1 июня 2009 в 10:16

Так же хочу напомнить, что по умолчанию есть возможность перекрывать хранилище перевода заменив стандартный модуль locale на свой (по сути переопределив функцию [ru-api=locale]locale()[/ru-api])

Аватар пользователя Химический Али Химический Али 1 июня 2009 в 10:57

<a href="mailto:andypost@drupal.org">andypost@drupal.org</a> wrote:
Так же хочу напомнить, что по умолчанию есть возможность перекрывать хранилище перевода

А примеры реализации имеются?

Аватар пользователя andypost@drupal.org andypost@drupal.org 1 июня 2009 в 12:00

Примеров нет, так пока не возникало необходимости, но смысл прост:

создаем свой модуль, который содержит функцию [ru-api=locale]locale()[/ru-api], отключаем тот который в ядре - соответсвенно все запросы на перевод из [ru-api=t]t()[/ru-api] будут приходить в нужное нам место.

Аватар пользователя Azerot Azerot 1 июня 2009 в 10:59

Классно. Вспоминаю свой пост почти годовой давности на drupal.org. Что характерно ни одного ответа на него не получил.
http://drupal.org/node/300978
Причём по-моему я предложил более удачный вариант, потому что он не требует указания специального контекста в большинстве случаев, потому что сам автоматически берёт нужный контекст, основываясь на имени файла, из которого произведён вызов функции t().

Аватар пользователя andypost@drupal.org andypost@drupal.org 1 июня 2009 в 12:03

Посмотрел я этот пост. Такие предложения не имеет смысла обсуждать на форуме, там в основном поддержка, а не разработка.

Самый эффективный путь - выдать issue в проект (очень желательно с патчем) и, например, на irc обсудить с мэйнтейнером.

Аватар пользователя Azerot Azerot 1 июня 2009 в 11:42

А как надо? Давно интересуюсь, что же и как надо сделать, чтобы хотя бы заметили, что написал.
Обсуждение рискует сьехать в оффтоп, но drupal.org у меня производит впечатление некой закрытой секты, куда допущен узкий круг посвящённых, а остальные идите лесом.

Аватар пользователя PVasili PVasili 1 июня 2009 в 11:48

"Azerot" wrote:
впечатление некой закрытой секты
- не совсем так.
На org довольно много разных предложений.
В модулях - если автор активный гораздо проще что-то полезное внедрить.
За ядром не так много народа следит. Все предложения отслеживать и испытывать ни у кого нет желания и физической возможности. Можно пробовать организовывать небольшие флеш-мобы, для джействительно полезных вещей. Проверенно - помогает Smile

Аватар пользователя Azerot Azerot 1 июня 2009 в 11:52

Я не говорю про внедрение - это уже предел мечтаний. Но хотя бы обсудить! Хотя бы написать - мол, мужик, ты бредишь и обосновать почему! А не так, что написал и тишина!

Аватар пользователя andypost@drupal.org andypost@drupal.org 1 июня 2009 в 12:12

На самом деле ядро очень большое и, объективно, весь его функционал мало кто знает! Для этого в корне инсталяции лежит MAINTAINERS.txt в котором написано, кто и за что отвечает.

Подход к включению в ядро довольно прост - если кроме запросившего на это issue никто не откликнулся, логично считать, что это никому не нужно и не стоит тратить время на даже на рассмотрение.

Вообще, Василий прав, нужно отдельную ветку на форуме сделать по проталкиванию разных проблем.

Аватар пользователя PVasili PVasili 1 июня 2009 в 12:28

"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:
отдельную ветку на форуме сделать по проталкиванию разных проблем
- поскольку большинства японцев не знает русский :), можно на drupal.ru обсудить полезность новшеств, открыть ветку с патчем на drupal.org и всем, не толпясь комментировать насколько это нужно и полезно :).
По опыту: из ~8 подобных случаев 6 были изменены и доработаны.

Аватар пользователя andypost@drupal.org andypost@drupal.org 3 июня 2009 в 4:04

У Вас есть идеи по добавлению "правил" и принципов?

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

Аватар пользователя alergi@drupal.org alergi@drupal.org 1 июня 2009 в 16:22

В принципе, нужная штука. Кнопки "просмотреть" и "изменить" в профиле совсем не в тему, да и "search" можно будет наконец нормально переводить, это в английском существительное и глагол одинаково пишутся, а нам надо писать в названии "Поиск", но в форме на кнопке "Найти".

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

Аватар пользователя neochief neochief 1 июня 2009 в 17:06

Не сильно в тему, но было бы неплохо иметь возможность указывать в locale(), в какую группу переводов этот перевод должен быть занесен.

Аватар пользователя andypost@drupal.org andypost@drupal.org 2 июня 2009 в 15:07

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

По идее контекста вполне должно хватить, но группа перевода используется по крайней мере для поиска строк

Аватар пользователя inc inc 2 июня 2009 в 13:54

Проталкивание решений силами русскоязычного сообщества - идея на миллион. Я руками и ногами за!!!

Зачем это нужно:
* На моей памяти был случай, когда в Drupal 4.7(в отличие от 4.6) перестали работать формы множественного числа для переводов. Разработчики обратили на это внимание и исправили только в версии 4.7.2( http://www.drupal.ru/node/1630 ).
* По собственному опыту: запостил на drupal.org свою модификацию одного модуля( http://drupal.org/node/203951 ), так maintainer ответил только спустя 2 месяца, когда у меня уже не было ни времени, ни желания заниматься дальнейшей модификацией этого модуля.

"<a href="mailto:andypost@drupal.org">andypost@drupal.org</a>" wrote:
Итак, чего же собственно Вас не устраивает в текущем подходе к переводу строк?

Низкая скорость работы модуля локализации - самый большой его минус ИМХО.

Аватар пользователя andypost@drupal.org andypost@drupal.org 2 июня 2009 в 15:11

Идея витает давно, но пока нет времени-сил довести до ума.

На www.drupaler.ru уже есть вписки модулей, даже с небольшим описанием каждого (спасибо Василию), теперь хорошо бы к каждому из них прикруть issues и настроить оповещения на почту - таким образом можно будет собирать отзывы и пожелания о конкретных модулях, а разработчики смогут на родном языке общаться и вносить изменения, которые потом можно будет проталкивать в официальные ветки или плодить форки.

Аватар пользователя neochief neochief 2 июня 2009 в 15:25

Другую группу стоит заводить, если ты хочешь хранить в таблицах локали переводы каких-то пользовательских данных (например, так нужно было бы сделать в первой версии api.drupal.ru, но тогда я еще об этом не знал, и как следствие, сейчас 4K сорцов апи в таблице локали перемешано с сорцами интерфейса). Еще одна полезность — ты можешь отдельно экспортировать po-файлы разных групп.

Реализация, на самом деле, элементарная — добавить один параметр в функцию и в запрос вместо 'default'. Странно, чего еще так не сделали. Надо бы глянуть в i18n, там есть функция tt(), в которой уже сделано что-то похожее.

Аватар пользователя andypost@drupal.org andypost@drupal.org 3 июня 2009 в 4:00

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

tt() таки намного умнее, но если уже в ядре есть возможность работать с разными группами - почему бы её не довести до ума?

Аватар пользователя Azerot Azerot 3 июня 2009 в 15:34

У меня вот была в своё время идея избавится от слов таксономия, словарь и термин, заменив их более понятными словами: категоризатор, группа категорий, категория. Однако термин категория уже занят в других местах, например применительно к новостям и формам обратной связи (контактам) - будет путаница.

Очень хотелось местами перевести Enabled не как Включено, а как Разрешено, не говоря уже о родовых окончаниях, которые к сожалению сейчас никак не привинтить: включен, включена и т.д.

Аватар пользователя Geldora Geldora 5 июня 2009 в 20:48

"Master of Tragedy" wrote:
Не, не 18, а 22 :)

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

Аватар пользователя PVasili PVasili 5 июня 2009 в 23:12

"Geldora" wrote:
, почему идею он взялся за переводы и многоязычие.
и не только за это :). Габр тянет и довольно много, не считая обычной поддержки а форумах.

Аватар пользователя andypost@drupal.org andypost@drupal.org 8 июня 2009 в 9:13

Ну вот и состоялось - патч прошел в ядро и теперь нужно пересмотреть вхождения строк и сделать ядро более "переводимым" Smile

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

Аватар пользователя PVasili PVasili 10 июня 2009 в 16:19

В настоящее время, сервер переводов поддерживает локальные клиенты. (Возможно отправлять переводы строк не сервер, при работе со своей локальной копией).
Настройка простая, "подробная инструкция" приложена.

Аватар пользователя Azerot Azerot 11 июня 2009 в 8:14

Не совсем понятно.
Получается у каждого пользователя своя локальная копия перевода на сервере локализации? Или нет и перевод на сервере локализации один? Если перевод один, то что произойдёт при попытке исправить уже существующий перевод?
Видимо инструкция нуждается в дополнительных пояснениях, потому что ответов на эти вопросы там нет.

Аватар пользователя Master of Tragedy Master of Tragedy 11 июня 2009 в 10:05

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

Аватар пользователя Azerot Azerot 11 июня 2009 в 10:58

Ясно. Следующий вопрос, на который мне так никто и не ответил ранее.
Что с авторскими правами на перевод?
Дело даже не в том, чтобы как-то выделится и поставить своё имя в ряд с прочими светилами (хотя а почему бы нет, если человек трудится, то пусть хотя бы признание получает, если не деньги), а в том, чтобы потенциально избежать возможных претензий в незаконном использовании чужого авторского материала. Допустим кто-то недобросовестный, выполнив множество переводов и загрузив их на сервер скажет - давайте бабки мне все, кто моими переводами пользуется - ведь я вам таких прав не давал! А кроме того, вы (даже согласно GPL и GFDL) не упоминаете моего авторства!
Ещё одна проблема - допустим я захотел убедить переводчика, что нашёл более правильный термин или нашёл ошибку в переводе. Прав на правку у меня нет - кому писать?

Аватар пользователя Master of Tragedy Master of Tragedy 11 июня 2009 в 13:52

У меня на сервере оговорена в футере лицензия по которой распространяются переводы. Думаю, Василию следует тоже это сделать для предотвращения подобных вопросов. Недобросовесный человек не будет выполнять много переводов и загружать их на сервер, контент которого на GNU GPL распространяется.
Каким образом будем указывать ваше авторство? Работа в большей части коллективная и результат принадлежит сообществу, а не конкретному автору.По-моему вполне справедливо. Может быть под каждой переведеной строкой подписывать ваше авторство,а? Чтобы все видели потом. Как такая идея?
Нашел более правильный термин - пиши переводчику с правами.

Аватар пользователя PVasili PVasili 11 июня 2009 в 14:13

Про копирайте и CC есть ветка давайте эти вопросы всё же туда...

"Master of Tragedy" wrote:
У меня на сервере оговорена в футере лицензия по которой распространяются переводы.
- я с удовольствием сделаю это, ибо это коллективный труд. Но я не знаю форму в которой это можно сделать(заявить) в России. Бардак(дороги и дураки...)
Я уже склоняюсь сделать как Дриса на drupal.org: выставить явно копирайт внизу сайта, дабы не возникало лишних инцидентов.

"Azerot" wrote:
Прав на правку у меня нет - кому писать?
: имея аккаунт на сервере переводов - отправьте запрос на вступление в соответствующую группу (того языка, на который хотите переводить). У вас появится соответствующий интерфейс для правки. Так же вы сможете отправлять переводы (автоматически), исправляя что-то у себя на сайте локальным клиентом.

Все получаемые с сервера переводы не содержат упоминания о копирайтах.
Пока только: http://drupaler.ru/translate/heroes содержит всех, кто внес свой вклад.

Аватар пользователя Azerot Azerot 11 июня 2009 в 15:03

Quote:
У меня на сервере оговорена в футере лицензия по которой распространяются переводы.

А модуль который будет позволять загружать переводы к вам на сервер будет показывать и заставлять акцептовать текст лицензии? Или просто при регистрации пользователя ему будет показана лицензия и только в случае её акцептования ему будет дозволено работать с сервером?

Quote:
Каким образом будем указывать ваше авторство? Работа в большей части коллективная и результат принадлежит сообществу, а не конкретному автору.По-моему вполне справедливо. Может быть под каждой переведеной строкой подписывать ваше авторство,а? Чтобы все видели потом. Как такая идея?

Ох уж мне эти переводы на личность Smile А спокойно без перевода стрелок на меня ответить ведь можно, да?
Работа безусловно коллективная, спору нет. Но вот давайте возьмём сам Drupal. Работа тоже коллективная, но что характерно каждый модуль имеет своего автора или авторов не так ли?
Нет безусловно, подписывать каждую строчку автором - это дурь несусветная, но добавлять автора перевода в заголовок .po файла (если такое кто захочет угрузить) а также хранить историю кто чего и когда добавил/изменил было бы очень даже разумно. В том же CVS репозитория кода Drupal можно найти кто автор тех или иных патчей и в итоге понять кто же писал код.

Quote:
Нашел более правильный термин - пиши переводчику с правами.

Мдя. Тоже выход конечно. Хотя "кто костюмчик пошил" всё-равно не понять.

Аватар пользователя PVasili PVasili 11 июня 2009 в 15:26

"Azerot" wrote:
А модуль который будет позволять загружать переводы к вам на сервер будет показывать и заставлять акцептовать текст лицензии?

Для локализации есть 2 модуля. Сервер и клиент. Оба вы можете использовать у себя.
1) На http://drupale.ru установлен сервер, в который собраны все существующие в рунете переводы модулей на нескольких языках.
Север позволяет при наличии определённых прав(я писал о них выше) получить доступ к добавлению/изменению существующих и новых переводов.
2) Локальный клиент позволяет переводить строки в вашей локальной установке.
3) Сейчас есть возможность удобно делиться данными со всеми (отправляя переводы на общий сервер). Ничего ни где акцептировать не нужно.

Сервер переводов хранит информацию об авторе каждой переведённой строки.
Студия Razgonka.ru был противником обезличенных переводов. Ничего не предложил и его вклад, репутация и польза для сообщество в этом вопросе в итоге = 0.
По поводу авторства - любые предложения приветствуются. Я не знаю как тут лучше поступить и сделать.

Аватар пользователя Azerot Azerot 11 июня 2009 в 15:35

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

По поводу авторства.
1. При получении .po файла с сервера переводов в нём должна быть информация обо всех участниках, которые занимались переводом строк в этом .po файле
2. При получении перевода клиентом, также неплохо бы выводить список переводчиков, которые занимались переводом с указанием ссылки, где можно получить этот список снова с указанием способа связи с автором (для целей отсылки ошибок авторам для последующего исправления).
3. Либо при получении прав на запись к серверу локализации, либо при загрузке переведённых строк на сервер локализации, пользователю должен выдаваться текст лицензии (достаточно одного раза), который должен им акцептоваться.

Аватар пользователя Azerot Azerot 11 июня 2009 в 15:36

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

Аватар пользователя andypost@drupal.org andypost@drupal.org 11 июня 2009 в 16:11

http://drupal.org/node/224333 # locale_context вот Габр описал нововведение по поводу контекста.

А по поводу сервера переводов, давай-те не засорять ветку!!! для этого есть другие темы и, собственно, форум на сервере переводов.

Аватар пользователя Azerot Azerot 11 июня 2009 в 22:10

locale_context - весьма нужная и полезная штука - стопудово! В семёрке я чую локализация интерфейса будет на более высоком уровне.

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

Аватар пользователя andypost@drupal.org andypost@drupal.org 11 сентября 2009 в 2:11

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

Это относится не только к контексту, но и к группам перевода

Также висит открытым вопрос контекста для JS http://drupal.org/node/488496