Pull to refresh

Comments 30

UFO just landed and posted this here
Гхм, а идею держать и русские и английские комментарии в коде отмели из-за разрастания собственно кода?
Это плохая идея, потребующая вдвое больше усилий на поддержку, не говоря уже о том, что придется постоянно следить, чтобы комментарии соответствовали и не противоречили не только коду, но и друг другу.

Комментарии (равно как и коммит-логи) должны быть только на английском (в идеале, на эсперанто, но не раньше чем он станет lingua franca, по крайней мере, в IT ;-).
Это плохая идея, потребующая вдвое больше усилий на поддержку, не говоря уже о том, что придется постоянно следить, чтобы комментарии соответствовали и не противоречили не только коду, но и друг другу.

Почему же? Разработчики работают только с комментариями на русском, а переводчик уже смотрит, какие из них изменились и переводит/правит.
Вот тут и заключается проблема:
а переводчик уже смотрит, какие из них изменились

Профессиональный перевод самостоятельно не сделать, для таких объемов текста тем более, поэтому тексты отдавались на перевод (на видео было сказано). Переводчиков на git-репозиторий не посадишь, поэтому так или иначе будут возникать проволочки коммуникации.
Вероятно вы просто невнимательно прочитали пост, все проблемы довольно подробно разобраны и описаны в причинах такого подхода.
То, что вы процитировали, исходило из этого:
Поэтому ребята написали простенький скриптик на Node.js, где Эми вбивает дату, и ей выводится список всех коммитов в коде за это время, которые содержат именно правки в комментарии.
(и далее по тексту)
Т.е. переводчик работает с репозиторием. И на этом уровне проблем бы не было.
У нас был опыт ведения международных проектов с переводами для двух и трех языков параллельно, причем к счастью не касающийся документации а только фронта. И при всем желании как только вы вводите непрофильного специалиста в воркфлоу профильного, потенциально создается дополнительная точка отказа. Согласен, что многое зависит от реализации, но к сожалению я не в курсе существования подобных успешных практик.

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

<sarcasm>
Давайте еще бухгалтерию на git пересадим.
</sarcasm>
будут присылать вам вордовские файлики

Если скажете TXT — будут TXT. И вообще в CAT (Computer-assisted translation) — что положишь — то и вынешь, только на другом языке. Переводчик тупо заменит одни текстовые строки на другие (а CAT обеспечит, чтобы он ничего не перепутал).

Переводчиков на git-репозиторий не посадишь

Почему? Они тоже люди. Вероятно, надо делать для них хранилище комментариев, с которым они будут работать как с текстом.

Так это не работает (вернее, будет работать плохо). Во-первых, комментарии должны по возможности всегда быть синхронны коду (и поэтому писаться программистом, который вносит соответствующие изменения); если их (комментариев) по два, это будет вызывать путаницу (успел ли переводчик перевести? устанешь постоянно svn blame говорить). Во-вторых, код — это субстрат (upstream), перевод — производный продукт (downstream); поддерживая двуязычные комментарии в коде, вы нарушаете это отношение, теперь у вас два апстрима и вытекающие из этого вопросы: где гарантия, что переводчик правильно понял/перевел исходный текст? кому верить? И потом, почему именно русский должен быть основным? А если команда международная? А если код захочется отдать в open source? Да и далеко не всем нравятся комментарии не на английском (независимо от родного языка).

Не говоря уже о том, что переводчик (как член documentation team) вообще, по-хорошему, не должен иметь прав на запись в репозиторий кода.
Ну, если предположить, что разработчики все же знают два языка, можно (зато) иметь две вещи — историю переводов в git, автоматику на уровне precommit-hook-а — если разработчик добавил текст в комментарий на русском, то не принимать коммит, если не добавлен текст в комментарий на английском (и наоборот). И повесить в postcommit hook нотификацию переводчика/редактора о пролезших изменениях.
в идеале, на эсперанто, но не раньше чем он станет lingua franca

Думаю что если не стал за более 100 лет с момента изобретения, то не станет уже никогда, к сожалению…
(ошибся веткой)
мы решили отказаться от комментирования кода на русском языке

отказываться от поддержки справочников на русском языке мы не хотели


Простите, это всё ещё 2017 год на дворе? Это всё ещё ИТ-компания? Или тут весь текст красненьким и смайлики «фейспалм» после каждого предложения?
UFO just landed and posted this here
Конечно не совсем в тему, но сделайте наконец таки полноценную поддержку ATS в своем SDK Yandex Maps для ios.
А то вопрос еще с прошлого года.
Спасибо.
Вот вы говорите, что отставание русского языка от английского сейчас не такое же большое, как было у английского относительного русского. Якобы это за счёт того, что вы разгрузили квалифицированного переводчика и для перевода с английского текста на русский вам достаточно неквалифицированного специалиста, что дешевле. Это, конечно, хорошо, но мне просто интересно, у вас английские комментарии к коду теперь из воздуха появляются или у вас все разработчики являются квалифицированными переводчиками? То есть раньше для ускорения процесса нельзя было нанять переводчика не особо высокой квалификации, который часть работы делал бы за Эми, потому что качество английского бы страдало. А теперь, когда у вас комментарии на английском пишут разработчики, качество английского не страдает?
Если у вас команда русскоговорящая, то раньше было что-то такое
  • разработчик думает -> разработчик пишет на русском -> Эми переводит -> получаем комментарии на двух языках

А сейчас у вас
  • разработчик думает -> разработчик переводит -> разработчик пишет -> переводят обратно на русский язык -> получаем комментарии на двух языках

Вы просто перевесили функции Эми на разработчиков, а в качестве костыля по поддержке русского языка добавили ещё один шаг. Так в чём профит-то?
Если считать, что разработчик на английском пишет в целом сносно, то вы просто отзеркалили ситуацию и проблемы английского языка перенесли на русский. Для международной компании так объективно лучше, только зачем вы тогда рассказываете про то, что вы избавились от проблем? Вы разве не просто перенесли проблему в другое место? Я признаю, что могу быть где-то неправ, опыта разработки чего-то у меня по нулям, но тогда объясните более понятно, почему проблема пропала
Единственно правильный workflow: разработчик думает -> разработчик пишет код и комментарии к коду на английском. Всё остальное уже потом (вне кода) и исходя из этой предпосылки.

Неважно, на-каком-языке-говорящая команда: public communications (включая код и комментарии) всё только на lingua franca английском; не умеют — учить. Не хотят — заставлять. Как иначе-то?
Видимо яндекс считает, что писать нормальные комментарии на русском стыдно, лучше писать комментарии с ошибками, но на английском, а потом переводить их обратно, добавляя еще ошибок.

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

Еще больший профит:
теперь комментарии на русском станут в два раза хуже, чем раньше были комментарии на английском.

Но… компания международная… и возможно в долгосрочной перспективе английский важнее качества, примерно как с AliExpress, перевод ужасен, но люди пользуются. Видимо на это и ставка.
Честно говоря, я не вижу никакой проблемы в комментариях на английском. Во-первых, разработчики обычно знают язык на достаточном уровне (не уверен в себе? попроси более подкованного товарища проверить текст), а во-вторых, технический английский довольно простой. Не думаю, что разница будет «теперь в два раза хуже».

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

качество вряд ли пострадает из-за смены языка.
Тут только ваше предположение против моего «в два раза хуже» (из-за двойного перевода), метрик все равно никто делать не будет :)
Нормально носители будут читать, пропущенные артикли никого особо не задевают
(прошу прощения, обычно я не делаю таких замечаний, но лишь в качестве иллюстрации: я же нормально читаю ваши на сколько, что бы и тоже самое). В крайнем случае, более лучше знающий язык коллега просто исправит комментарий (грамматику), problem solved. ;-)

(Возможно, я преуменьшаю проблему, т.к. сужу в основном по open source проектам; в частных конторах ситуация может быть хуже, но как бы там ни было, отказ от русскоязычных комментариев это имхо шаг в правильную сторону.)
А что вы имеете против «на сколько»?
:) В остальном да, бывают и не такие очепятки, когда особо не концентрируешься на проверке орфографии, а важно изложить смысл. Я не носитель английского языка, поэтому не могу судить о том, на сколько сильно они цепляются глазу, возможно, вы правы и здесь проблем нет. Но я имел опыт чтения комментариев китайских коллег, пытавшихся писать на русском, это… как бы по мягче сказать… зрелище не для слабонервных, а править за ними — это тратить свое личное время и силы. Перевод — дело тонкое Петруха :)

отказ от русскоязычных комментариев это имхо шаг в правильную сторону
Возможно да, а возможно и нет, весь вопрос в том, на сколько это в итоге напряжно для самих разработчиков API.
UFO just landed and posted this here
По словам той стороны, они проходили спец.курсы плюс изучение языка в ВУЗе, как на самом деле не знаю, работали удаленно.
А что вы имеете против «на сколько»?
В данном случае это слово пишется слитно.
Я не носитель английского языка, поэтому не могу судить о том, на сколько сильно они цепляются глазу, возможно, вы правы и здесь проблем нет.
Я тоже далеко не носитель (более того, тест на артикли я, можно сказать, едва прошел на трояк). Так вот: носители не парятся по поводу ошибок, тем более допускаемых не-носителями.

Ну а китайцы, которых просят писать на русском(!), это, конечно, сильно. Более идиотского требования сложно придумать.
На сколько
Напомню контекст: «Правда, не знаю, на сколько эти комментарии будет приятно читать носителю языка.»
Правило
Отличаем местоимение «на сколько»

А сейчас рассмотрим иной контекст:
На сколько частей разделим яблоко?
Я не знаю, на сколько частей нужно разделить яблоко.

В этих предложениях употреблено вопросительное и относительное местоимение в форме винительного падежа. У местоимения есть зависимое слово — существительное «частей», что кардинально отличает его от похожего по звучанию наречия «насколько». Местоимение с предлогом пишется раздельно.


Ну а китайцы, которых просят писать на русском(!), это, конечно, сильно. Более идиотского требования сложно придумать.
В таком случае, требование писать русских на английском или китайском вам должно казаться не менее идиотским, верно? ;)

Если вы используете иностранный язык для перевода технических статей на свой язык для понимания технологии (не используете в повседневном общении), это не говорит о том, что вы сможете писать на иностранном языке так, как это делает человек пользующийся этим языком с рождения. Скорее всего ваш перевод будет не сильно отличаться от машинного. Нормально переводить могут профессиональные переводчики, носители языка либо не носители, которые постоянно общаются на этом языке с носителями. Естественно все они должны быть знакомы с предметной областью.
Правильно так: «Правда, не знаю, насколько (в какой мере, степени — прим. моё) эти комментарии будет приятно читать носителю языка.»
В таком случае, требование писать русских на английском или китайском вам должно казаться не менее идиотским, верно?
Нет, не верно. Писать надо на lingua franca в своей области. На сегодня в IT это английский.
Скорее всего ваш перевод будет не сильно отличаться от машинного.
Если я буду переводить на арабский или суахили, то, скорее всего, да. Но речь про английский.
:) Выше опечатка не «русских», конечно а «русским».
Нет, не верно. Писать надо на lingua franca в своей области. На сегодня в IT это английский.
Если в международный open source, то тут соглашусь смыл есть, в остальном зависит от проекта. Для коммерческих, это может быть совершенно не верным утверждением.

Если я буду переводить на арабский или суахили, то, скорее всего, да. Но речь про английский.
Тут наверно больше спорить не имеет смысла, так как уровень владения английским у всех разный, я просто поделился опытом носителя языка, который читал тексты переведенные на русский не носителями этого языка, вот и всё. Если вы уверены, что ваш английский не является корявым для англичан/американцев — вы молодец. А если в проекте все из разных стран и пишут на английском (lingua franca), хотя ни англичан ни американцев в проекте нет… это вообще идеально, тут никто никакой корявости и не увидит.

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

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

Планируется ли в файле API https://api-maps.yandex.ru/2.1/?lang=ru_RU поддержка AMD или UMD?

Sign up to leave a comment.