company_banner

Локализация комментариев в коде. Лекция Яндекса

    В процессе выхода на международный рынок с API Карт мы решили отказаться от комментирования кода на русском языке. При этом на основе комментариев формируются справочники сервиса, которые затем публикуются у нас на портале, и отказываться от поддержки справочников на русском языке мы не хотели. Из доклада Олеси Горбачевой и Максима Горкунова вы узнаете, как технические писатели Яндекса совместно с разработчиками API Карт поменяли язык комментариев и организовали синхронную поддержку справочников и примеров сразу на двух языках.


    — Меня зовут Олеся, я занимаюсь документированием API Карт. Выступать я буду не одна, со мной будет мой коллега Максим — ответственный за инструменты локализации в Яндексе.

    Сегодня мы расскажем о том, как мы поменяли язык в комментариях в коде JS API Карт. Что мы сделали? Все комментарии, которые были на русском языке в коде, поменяли на английские комментарии. По ходу доклада мы расскажем, почему пришлось переводить комментарии в коде, в чем сложность этой задачи, и как это повлияло на нашу систему автогенерации документации из кода. Нам пришлось переводить не просто комментарии в коде, а документационные, на основе которых мы формируем и публикуем справочники API в Яндексе. Над этой задачей трудились не только служба документации и локализации, но и команда API Карт, эти веселые ребята являются заказчиками задачи, виновниками торжества.

    Как возникла задача перевода комментариев в коде? Вернемся в прошлое, когда код еще документировался на русском языке. На прошлом Гипербатоне в прошлом году я уже рассказывала, что для документирования кода у нас используется инструмент JSDoc.


    Разработчики размечали код на русском языке в соответствии с требованиями JSDoc. Я при необходимости эти требования вычитывала, вносила правки и коммитила в код.

    Какие справочники мы поддерживали? В первую очередь, код на русском языке. DITA XML — это формат представления нашей документации, подробнее об нем — в докладе Леши Миронова. Вот пример собранного справочника, который можно посмотреть здесь.

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

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

    Поэтому мы накапливали пачку изменений и отдавали справочник на перевод раз в несколько месяцев. И английский справочник отставал от русского. На тот момент русская документация была более приоритетной, и для нас это было приемлемо.

    Время шло, API Карт развивался, и рост аудитории в мире стал значительным.



    Нам чаще стали писать люди из разных уголков планеты с вопросом об использовании API Карт и вопросами к документации — почему у нас там устаревшая версия. В тот момент мы начали задумываться, полгода назад, что, во-первых, Яндекс — международная компания, а API карт — масштабный проект. И любой пользователь в мире может открыть код и увидеть русские комментарии. Это неправильно.

    Кроме того, на тот момент разработчики стали выпускать для работы с API внешние модули, которые лежат на GitHub, и документация к ним сразу пишется на английском. И давайте не забывать про отставание английского справочника. Взвесив все это, мы подумали, что надо переводить все комментарии на английский, и дальше писать уже сразу на английском.

    В чем сложность задачи? Мы подсчитали, что на тот момент в коде API карт было ровно 4703 комментария. Некоторые из них достаточно большие. Это один фрагмент, один комментарий. Они не все такие длинные, но тем не менее.



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

    Нам не хотелось переводить вручную. Мы не хотели руками копировать, переводить и обратно копировать в код 4700 комментариев. Мы хотели автоматически извлекать комментарии, и на их места вставлять перевод, сохраняя скелет JS-документа, все JSDoc-теги, их валидность, ну и не ломая сам код. О том, как мы это делали, расскажет Максим.

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

    Нам надо было найти в JS-коде все описания классов, объектов и методов, потом текстовые описания ко всем параметрам и представить весь этот текст в виде XLIFF-файла. В Яндексе мы все стремимся переводить через XLIFF, у нас для этого отлажены процессы, существуют фермы переводов, сервер для хранения translation memory, ТМ. Фактически нужно было из всех JS-скриптов сделать XLIFF и перевести его в Cat tool. Для этой задачи мы использовали Okapi Framework, мощный опенсорсный инструмент, который мы применяем для автоматизации задач локализации.

    Мы брали исходный JS-файл из репозитория, убеждались, что он удовлетворяет требованиям, кодировке UTF-8, одинаковому окончанию строк — это важно для работы Cat tool.

    Дальше нужно было их подготовить, чтобы применить один из фильтров Okapi. Хотя JSDoc — самый мощный инструмент для документирования JS-файлов, готового фильтра для него не существует. Нам пришлось как-то выкручиваться. Мы использовали ближайший по смыслу фильтр из набора Okapi Framework, который извлекает комментарии Doxygen. Это другая система документирования кода, которая в основном используется для комментариев в С++, Java- и, возможно, в Python.

    Формат этих комментариев очень схож. Фактически нам надо было подделать эти JS-файлы, привести их такому виду, который ожидал Doxygen-фильтр. Различия заключались в основном в звездочках, слэшах. Допустим, требовалось три слэша для отбивки комментария, а не два, звездочек тоже должно быть две, а не одна. Мы немного видоизменили этот код. С точки зрения программистов он тогда стал невалидным, но поскольку эти фильтры его не разбирают, это все равно что текстовый файл, то нам это было неважно.

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

    Дальше мы изготовили пайплайн. В терминологии Okapi Framework это последовательность шагов, которая приведет нас к созданию XLIFF. Далее был шаг сегментации. У нас существуют правила в виде файлов SRX для русского языка, которые позволяют разбить большие блоки текста на отдельные предложения. Это повышает процент совпадения из ТМ, поскольку фрагменты памяти становятся мельче.

    Дальше мы применили имеющийся ТМ, который у нас остался из справочника, получили нечеткие и четкие совпадения и дальше переводили полученный огромный XLIFF-файл в Cat tool.

    Здесь мы использовали XLIFF-файл, поскольку он хорошо дружит с Okapi, и эти XLIFF можно переводить в онлайн-инструменте.

    Дальше нужно было отредактировать полученный перевод и проверить, все ли получилось, на месте. Тут была довольно сложная задача из-за специфики комментариев и отбивки звездочками. Нужно было убедиться, что если в нашем варианте было пять строчек, то и в переводе должны быть те же пять строк, иначе разъедется огромная простыня, будет нарушено форматирование. Для этого мы написали специальную исправлялку пропущенных пробелов, переводов строк, а также хитро проверяли наличие инлайновых тегов. Если что-то было пропущено — подставляли их из source.

    Затем мы извлекли полученную ТМ для дальнейшего использования.

    Нам нужно было сделать постпроцессинг, целиком зеркальный препроцессингу. Мы должны были получить обратно валидный JS-файл, убрав все то, что было нужно для работы фильтра Doxygen.

    В итоге мы получили тот же самый набор JS-файлов, но все комментарии уже были на английском языке. Разработчики команды Карт написали тесты и убедились, что все наши изменения происходили только в тех областях, где находились комментарии, то есть никакой код мы не попортили. Вот такое было приключение.


    — В качестве демонстрации — фрагмент из текущего исходника кода. Но на этом задача еще не была решена до конца. Нужно было продумать, кто будет редактировать английские комментарии в коде и, главное, как?

    И нам нужно было адаптировать систему автогенерации, ведь язык комментариев теперь изменился. Как мы это решали? Редактором переводов мы выбрали нашего переводчика Эми. Эми переводит практически всю техническую документацию в Яндексе, в частности API Карт. Разработчики карт хотели упростить Эми жизнь по максимуму. Они не хотели, чтобы Эми отслеживала вручную все изменения в коде, в комментариях, и чтобы ей не пришлось самой работать в консоли с командами Git.

    Поэтому ребята написали простенький скриптик на Node.js, где Эми вбивает дату, и ей выводится список всех коммитов в коде за это время, которые содержат именно правки в комментарии.

    Например, Эми переходит по одному из них, попадает в интерфейс нашего внутреннего GitHub, и там зелененьким подсвечивается, какие правки были внесены в комментарий. Эми вычитывает, по необходимости правит, и коммитит в код прямо по кнопке. Все просто. Конечно, здесь нужно быть аккуратным, чтобы не закоммитить ничего лишнего. Также Эми фиксирует все типовые ошибки, которые мы совершаем, вычитывая код. Речь про ошибки, которые мы совершаем при написании текстов на техническом английском. Здесь пример с ошибками в артиклях, но таких табличек намного больше. Это хорошая практика для того, чтобы в будущем избежать подобных ошибок.

    Как мы настраивали и адаптировали систему автогенерации. Давайте вернемся в прошлое и представим, что у нас комментарии в коде на русском языке. Как раньше формировались API?

    Для формирования русского справочника мы исходный код API с русскими комментариями прогоняли через JSDoc. Нужно было какое-то время подождать, и JSDoc отдавал нужную DITA XML, готовый справочник, который мы публиковали на нашем домене ru. Тут просто.

    Как мы получали английский справочник из русских комментариев?

    Мы брали русский код, снова прогоняли его через JSDoc отдельной итерацией, но мы настраивали специальный шаблон, локализованный под английский язык. Например, название таблиц было сразу на английском. Наличие такого шаблона я помечу английским шлемом. Нам английский JSDoc отдавал DITA XML, но по-прежнему с русским описанием, которое мы отдавали на перевод. Эми переводила и возвращала мне DITA XML на английском языке, готовый справочник, который можно публиковать на домене com.

    Хорошо, но это было раньше. Теперь все поменялось, комментарии на английском языке. Как мы собираем английский справочник? Так же, как раньше собирали русский. Берем исходный код, прогоняем через программку-англичанина JSDoc, и получаем английские исходники, которые мы публикуем на домене com. Что же с русским справочником? Код с английскими комментариями, и у нас есть ТМ, память переводов, которую мы накапливали годами.

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

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

    В качестве переводчика здесь уже выступаю я. Каждый раз, когда мне нужно публиковать русский справочник, я вначале собираю английский, в инструменте Swordfish делаю перевод недостающих фрагментов текста, ранее непереведенных, и далее мы публикуем. Помните улитку, показывающую, что сначала справочник, который мы переводили, всегда отставал? Сейчас главное было, чтобы русский справочник не отставал. В первую очередь, время сократилось за счет того, что переводом занимаюсь я. Не нужно стоять в очереди на перевод: открыл, перевел пару строк и сам все собрал.

    А синхронизировать справочники нам помогла программа TeamCity. Это инструмент от JetBrains, который позволяет автоматизировать многие процессы вашего проекта. Достаточно мощная штука.



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

    В чем же плюсы локализации комментариев в коде? Во-первых, теперь API Карт содержат английские комментарии, поэтому любой разработчик из любой точки мира может увидеть английский язык. Во-вторых, наконец-то мы настроили оперативную выкладку английских документов. В-третьих, мы сняли нагрузку с переводчика — теперь Эми не надо каждый раз переводить эти справочники. И наконец, если когда-нибудь нам придется переводить справочники на другие языки, то выполнять перевод с английского намного проще, чем с русского.

    Это списки инструментов, которые мы используем в проекте. Спасибо!
    Яндекс 248,43
    Как мы делаем Яндекс
    Поделиться публикацией
    Комментарии 30
      +7

      Скажите зачем вы заменили комментарии. Почему просто не добавили перевод?
      Нужно быть воистину уверенным в себе, чтобы верить, что в таком количестве текста 100% верео передан смысл.

        +2
        Гхм, а идею держать и русские и английские комментарии в коде отмели из-за разрастания собственно кода?
          +1
          Это плохая идея, потребующая вдвое больше усилий на поддержку, не говоря уже о том, что придется постоянно следить, чтобы комментарии соответствовали и не противоречили не только коду, но и друг другу.

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

                                0

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

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

                                Самое читаемое