Ситуация с переводами растбука


#11

еще и бета есть: https://doc.rust-lang.org/beta/book/foreword.html


#12

Кстати, надо бы поднять вопрос о смене этой ссылки в самом растбуке на какой-то актуальный перевод (как я понимаю, сейчас это https://github.com/kinoher/rust_book_2ed / rustbook.ru).

UPD: Вообще, перед возобновлением активной работы над переводами, не помешало бы как раз вот этой нарождающейся в соседней теме командой (комитетом?) решить что и как будет организованно + выбрать ответственных за состояние перевода. Потому что сейчас инфраструктура перевода правда в фиг поймешь каком состоянии находится.


#13

Связаться с мозиловцами, теми кто в основном пишет доку (клабник и 10 центов) будет возможность, у кого то остались контакты? Чтобы связаться, внести предложения, услышать их мнение? Без поддержки с их стороны ввести эффективный процесс перевода будет сложно, имхо.


#14

по поводу перевода растбука. Он часто обновляется, но документация все равно на русском нужна


Потенциальный список команды сообщества
#15

Мое отношение к переводам вообще, а к переводам документации в частности за последний год изменилось на 180 градусов. Не вижу в этом никакого смысла. Разработчик должен знать международный английский, актуальность перевода контролировать чрезвычайно сложно, вложенные усилия вряд ли когда-нибудь окупятся. Переводить книги (бумажные) или статьи - полезно. Переводить документацию - сложно и вредно.


#16

С нуля — сложно и вредно, а если есть метки и изменения в оригиналах делают согласно оговореной практике, то легко и просто обновлять только то, что действительно меняется. А меняется оно не по 60-80% от общего объёма, а гораздо более мелкими кусками.

UPDATE:
Основная и муторная проблема - это удобно, быстро и качественно трэкать, где и что изменилось. Когда перевода уже много, то высматривать все глазами - это застрелиться, высматривать глазами комиты - полегче, но тоже муторно.


#17

Скорее, надо URLO/IRLO темы по этому поводу поднять для начала, типа таких - https://internals.rust-lang.org/t/better-support-translations-for-the-book/3003 - мысль-то, что перевод делать не удобно, не сильно свежая.


#18

Перечитал, все поинты в теме валидные. Основная проблема — это трекинг мелких изменений из оригинальных англ источник, это звучит от всех.
— мульти-языковое меню
— гит комиты (все или ничего)
— транзификс сервис
Тоже валидные предложения и замечания.
Отпишусь туда и подниму тему.


#19

Ну это вообще не проблема. Берем фиксированный релиз, переводим всю книгу. Затем берем обновленный релиз и делаем git diff release_old..release_new, получаем общий дифф изменений, с которым затем уже можно работать.

Быстро трекать изменения не надо, надо трекать изменения релизов. Следовательно переводы растбука должны быть привязаны к релизу оригинала (и это надо указывать в заголовке перевода).


#20

Ну ок, хорошее замечание — работаем исключительно с релизами, трэкать рабочие версии не хотим.
Это как? Снова с нуля, с начала все переводим?

Ну вот есть полотно изменений между релизами, разных изменений в разных файлах: 1) что то обновилось по тексту (совпадает или отличается на 0-10–80%), 2) что то по тексту осталось на 100% тем же, но переехало в новое место (в том же файле или в другой файл) , 3) что то добавилось полностью новое, 4) что то удалилось полностью или частично, где то микс случаев 1)+2) и тд.

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


#21

Я не про edition.

А часто такое случается?

Зависит от того, как колбасит текст. Надо смотреть на реальные диффы, чтобы понимать, насколько часто встречаются 1) 2) 3) 4) случаи, чтобы выработать стратегию.


#22

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


#23

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


#24

Не уверен, что git-а будет достаточно. Не зря в internals парень упоминает transfix сервис, который умеет много полезного для переводчиков, но проблемно интегрировать с гит-ом и стало быть для писателей из мозиллы.


#25

жесть, сложно там все.


#26

Не супер сложно, потому что нужно принять решение “как сделать” и пробовать так сделать (MDbook код модифицировать в первую очередь под это). В принципе оба подхода будут работать, что то лучше, что то похуже, но будет.

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

Уход Клабника — да, приведёт к задержке во всей этой теме. Кто там дальше будет вместо него — будет видно.


#27

Кстати, по ссылке [https://github.com/kinoher/rust_book_2ed ] достаточно много ошибок орфографии и поставлены неправильные обороты и слова. Такое ощущение иногда. что просто чрез гугл прогнано и не всегда проверено и вычитано


#28

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


#29

У кого какие предложения? будем переводить или нет? В каком это виде у нас будет? Можем много говорить, но так ничего и не делать


#30

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

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