Как минимум, запятая перед that ошибочна во втором примере.
Допустим запятой там нет. Тогда второй пример означает, что определением SSL-протокола является то, что он широко распространен. Это несколько лишено смысла :)
Суть проста — which вводит дополнительную информацию, а that — определяющую. Собственно, об этом в статье и написано.
Я имел ввиду, что зарплата техписа в среднем по рынку ниже, чем зарплата аналитика. Значит если техпис делает работу аналитика за зарплату техписа, значит это аналитик, которому не доплачивают. За зарплату разработчика поработать аналитиком наверное не так уж плохо.
На концепции и справочники лучше всего ссылаться в тексте при первом упоминании термина. Например, в гайде "Как настроить VPN" в первой строчке у вас будет "Чтобы настроить [VPN](ссылка на концепцию, где описано что такое VPN) : ...".
А на гайды и туториалы можно ссылаться в конце раздела или параграфа. То есть в конце концепции "Что такое VPN?" у вас будет параграф типа "См. также: Как настроить VPN, Настраиваем VPN на iOS (ссылки на гайды и туториалы, соотвтетственно)".
Но это всё не правила, просто рекомендации из моего опыта. Нужно смотреть по возможности и здравому смыслу где ссылки на другие разделы будут уместны.
Спасибо за развернутый ответ. Я с геймдев-документацией не сталкивался еще, поэтому может быть какой-то специфики не понимаю. Хотя это очень интересно должно быть.
Ваша статья могла бы быть более увлекательной, если бы вы о таких неочевидных и специфичных вещах в ней последовательно написали. Без связующих пояснений цели, задач и процесса разработки документации, статья выглядит как набор случайно взятых фактов и советов. Отсюда впечатление, что статью писал ИИ.
Как-то сумбурно получилось, вы точно не ChatGPT? :)
О какого рода документации вообще речь? В начале вы говорите о требованиях, то есть о проектной документации. Затем вы упоминаете актуальность и доступность документации для пользователей, то есть теперь говорите о пользовательской документации. Затем речь опять заходит про требования, то есть опять про проектную.
У этих видов документации разные цели и задачи, разная аудитория, по идее ее пишут разные люди и на разных этапах жизненного цикла продукта. Наверное и подходы к тестированию совершенно разные должны быть.
Каким образом читы относятся к разработке доки тоже тема не раскрыта.
Перевод художки это вообще только по призванию и только если у вас есть кто-то, кто готов вас содержать, так как есть будет нечего. За это платят часто даже меньше, чем техническим переводчикам низшего звена, а труд титанический. Нужно самому быть художественным писателем по сути. А автопереводу нормальная художка не поддается, смысла в нем нет.
Отвечу на правах бывшего технического переводчика.
Вынужден не согласится с самым первым вашим утверждением. Переводы дело нудное только если вы не любите переводить. Для того, кто любит, это увлекательный процесс. А вот про неблагодарное и малооплачиваемое полностью согласен с вами.
Далее. Не обязательно досконально и глубоко понимать написанное, а тем более применять на практике в программировании, чтобы нормально перевести. Перевод несомненно требует погружения в предметную область, но на существенно меньшую глубину, чем та, которая нужна программисту для практики. Но просто хороший переводчик, как минимум, разберется в принятой терминологии и таких ляпов как тут не допустит. Какие-то тонкие моменты от переводчика, конечно, могут ускользнуть. В нормальном мире мире розовых поней и эльфов в этот момент в игру вступает технический редактор, который как раз проверяет текст на технические неточности.
Проблема в том, что как хорошего переводчика, так и ответственного технического редактора нужно сперва найти, что непросто, когда каждый первый считает, что способен быть переводчиком (это не так, ребята). Потом им нужно заплатить столько денег, чтобы они не только покушать, но и за коммуналку заплатить смогли. В целом этого достаточно, чтобы книжка получилась норм. Но, видимо, ответственный за издательство этой книжки решил сэкономить и нанял первого попавшегося первокурсника за 150р./стр., а с поиском технического редактора вообще не парился.
Еще могу почти наверняка сказать, что это не машина переводила. Машины не ошибаются так тупо при переводе групп существительных с артиклем типа "a classification algorithm".
Помилосердствуйте! "Чистой" энергии не существует. Или во всяком случае не открыто и даже в теории не предсказано. Наверное вы хотели сказать "энергия бозонов"?
Ландау, Лифшиц, "Квантовая механика". В начале книги (где-то до 20 страницы) дано довольно четкое и понятное определение понятию "наблюдение": взаимодействие квантового объекта с макроскопическим.
Оставьте пустые "философские" спекуляции на эту тему, к науке они точно не имеют отношения.
Объясните как работает "Секретная номинация"? Туда попадут статьи, которые жюри сочтут не вполне подходящими по тематике под другие номинации? Или по-другому?
Если я вас правильно понял, вы спрашиваете, может ли использование определяющих существительных приводить к двусмысленности и разным трактовкам? Да, может. За этим надо стараться следить и не допускать.
Это предложение я привожу как раз как пример того, как не надо делать, но я и сам не заметил, что здесь есть еще и такой аспект, как двусмысленность. Спасибо за это наблюдение!
Если же рассматривать словосочетание thetext identifier отдельно, то оно, конечно, тоже может читаться как "идентификатор текста". И я мог бы придумать примеры, где это будет иметь смысл. Но если предложение составлено нормально, то однозначность рождается контексте: The field contains the text identifier of the system error message. Сложно здесь проинтерпретировать неправильно.
Да, тоже интересный пример. Как я сказал в самом начале статьи, артикли — это самая сложная тема для нас. Я бы тоже в обоих случаях the использовал, но тоже не могу уверенно объяснить почему. Есть, кстати, похожая идиома, а еще книжка с таким названием.
Согласования артиклей, как мне кажется, не существует. Выбор от каждого конкретного существительного зависит.
Насчет the user, в документации он не абстрактный. Это как раз случай "объявленной" сущности. Даже если в тексте ни разу не встретилось a user, читатель понимает что речь идет о некоем одном и том же живом пользователе.
Кстати, полагаться на техническую документацию при проверке употребимости тех или иных норм языка нужно очень осторожно. Сперва убедитесь, что она написана грамотными носителями языка. Мой опыт технического переводчика говорит, что это в 80% случаев не так.
Это действительно довольно любопытный пример. Давайте разберемся.
В данном случае под man понимается не настоящий человек, а некий абстрактный собирательный образ человека. Поэтому ни a, ни the здесь не подходит. Я как-то поленился упомянуть про этот случай в статье, т.к. он нечасто на мой взгляд встречается в технических текстах, но если существительное используется в качестве абстрактного образа предмета, то артикль перед ним не ставится.
Лучше всего этот принцип проиллюстрировать на пицце:
I called for a pizza — Я заказал пиццу (какую-то одну, но какую не важно).
The pizza is still hot — Пицца (конкретная) еще горячая.
I like pizza — Я люблю пиццу (но не какую-то конкретную, а пиццу в целом, как явление).
В данном случае человек — это пицца :)
Теперь ко второй проблеме. Почему у абстрактного человека "конкретные" руки? Здесь я не вижу такого однозначного и простого ответа, но думаю, что здесь идёт противопоставление с руками Господа, которые абсолютно точно the, хотя они тоже абстрактны, ведь это выражение в переносном смысле, речь не идет о физическом падении в руки. И когда речь заходит о руках человека, то артикль показывает что эти "руки" используются в том же переносном смысле, что и при первом упоминании. Как-то так.
На тему артиклей есть еще одна хорошая иллюстрация, кстати.
Спасибо за отзыв!
Про пусек бятых я, кстати, не знал. Думал про другой хрестоматийный пример — Глокая куздра :)
Товарищи синьор-разрабы, проходите мимо, не задерживайте очередь, это не для вас написано :)
Как минимум, запятая перед that ошибочна во втором примере.
Допустим запятой там нет. Тогда второй пример означает, что определением SSL-протокола является то, что он широко распространен. Это несколько лишено смысла :)
Суть проста — which вводит дополнительную информацию, а that — определяющую. Собственно, об этом в статье и написано.
С этого ошибочного варианта мы и начали блок :)
Я имел ввиду, что зарплата техписа в среднем по рынку ниже, чем зарплата аналитика. Значит если техпис делает работу аналитика за зарплату техписа, значит это аналитик, которому не доплачивают.
За зарплату разработчика поработать аналитиком наверное не так уж плохо.
Зависит от команды, но вообще по-хорошему любое ТЗ пишет аналитик. Если ТЗ пишет техпис, то он и есть аналитик, просто ему недоплачивают.
Хороший вопрос, спасибо.
На концепции и справочники лучше всего ссылаться в тексте при первом упоминании термина. Например, в гайде "Как настроить VPN" в первой строчке у вас будет "Чтобы настроить [VPN](ссылка на концепцию, где описано что такое VPN) : ...".
А на гайды и туториалы можно ссылаться в конце раздела или параграфа. То есть в конце концепции "Что такое VPN?" у вас будет параграф типа "См. также: Как настроить VPN, Настраиваем VPN на iOS (ссылки на гайды и туториалы, соотвтетственно)".
Но это всё не правила, просто рекомендации из моего опыта. Нужно смотреть по возможности и здравому смыслу где ссылки на другие разделы будут уместны.
Для примера можете посмотреть как на пошаговые инструкции ссылаются из концепций, и наоборот, на Яндекс Облаке: https://cloud.yandex.ru/docs/managed-postgresql/concepts/backup
Союз айтишников России не за горами. Будут решать кто программист, а кто нежелательный элемент.
Спасибо за развернутый ответ. Я с геймдев-документацией не сталкивался еще, поэтому может быть какой-то специфики не понимаю. Хотя это очень интересно должно быть.
Ваша статья могла бы быть более увлекательной, если бы вы о таких неочевидных и специфичных вещах в ней последовательно написали. Без связующих пояснений цели, задач и процесса разработки документации, статья выглядит как набор случайно взятых фактов и советов. Отсюда впечатление, что статью писал ИИ.
Как-то сумбурно получилось, вы точно не ChatGPT? :)
О какого рода документации вообще речь? В начале вы говорите о требованиях, то есть о проектной документации. Затем вы упоминаете актуальность и доступность документации для пользователей, то есть теперь говорите о пользовательской документации. Затем речь опять заходит про требования, то есть опять про проектную.
У этих видов документации разные цели и задачи, разная аудитория, по идее ее пишут разные люди и на разных этапах жизненного цикла продукта. Наверное и подходы к тестированию совершенно разные должны быть.
Каким образом читы относятся к разработке доки тоже тема не раскрыта.
Перевод художки это вообще только по призванию и только если у вас есть кто-то, кто готов вас содержать, так как есть будет нечего. За это платят часто даже меньше, чем техническим переводчикам низшего звена, а труд титанический. Нужно самому быть художественным писателем по сути. А автопереводу нормальная художка не поддается, смысла в нем нет.
Почему бы издательствам не завязать издавать то, что не могут себе позволить качественно перевести?
Отвечу на правах бывшего технического переводчика.
Вынужден не согласится с самым первым вашим утверждением. Переводы дело нудное только если вы не любите переводить. Для того, кто любит, это увлекательный процесс. А вот про неблагодарное и малооплачиваемое полностью согласен с вами.
Далее. Не обязательно досконально и глубоко понимать написанное, а тем более применять на практике в программировании, чтобы нормально перевести. Перевод несомненно требует погружения в предметную область, но на существенно меньшую глубину, чем та, которая нужна программисту для практики. Но просто хороший переводчик, как минимум, разберется в принятой терминологии и таких ляпов как тут не допустит. Какие-то тонкие моменты от переводчика, конечно, могут ускользнуть. В
нормальном миремире розовых поней и эльфов в этот момент в игру вступает технический редактор, который как раз проверяет текст на технические неточности.Проблема в том, что как хорошего переводчика, так и ответственного технического редактора нужно сперва найти, что непросто, когда каждый первый считает, что способен быть переводчиком (это не так, ребята). Потом им нужно заплатить столько денег, чтобы они не только покушать, но и за коммуналку заплатить смогли. В целом этого достаточно, чтобы книжка получилась норм. Но, видимо, ответственный за издательство этой книжки решил сэкономить и нанял первого попавшегося первокурсника за 150р./стр., а с поиском технического редактора вообще не парился.
Еще могу почти наверняка сказать, что это не машина переводила. Машины не ошибаются так тупо при переводе групп существительных с артиклем типа "a classification algorithm".
Помилосердствуйте! "Чистой" энергии не существует. Или во всяком случае не открыто и даже в теории не предсказано. Наверное вы хотели сказать "энергия бозонов"?
Читайте классику.
Ландау, Лифшиц, "Квантовая механика". В начале книги (где-то до 20 страницы) дано довольно четкое и понятное определение понятию "наблюдение": взаимодействие квантового объекта с макроскопическим.
Оставьте пустые "философские" спекуляции на эту тему, к науке они точно не имеют отношения.
Объясните как работает "Секретная номинация"? Туда попадут статьи, которые жюри сочтут не вполне подходящими по тематике под другие номинации? Или по-другому?
Не сдавайтесь! :)
Если я вас правильно понял, вы спрашиваете, может ли использование определяющих существительных приводить к двусмысленности и разным трактовкам? Да, может. За этим надо стараться следить и не допускать.
Это предложение я привожу как раз как пример того, как не надо делать, но я и сам не заметил, что здесь есть еще и такой аспект, как двусмысленность. Спасибо за это наблюдение!
Если же рассматривать словосочетание the text identifier отдельно, то оно, конечно, тоже может читаться как "идентификатор текста". И я мог бы придумать примеры, где это будет иметь смысл. Но если предложение составлено нормально, то однозначность рождается контексте: The field contains the text identifier of the system error message. Сложно здесь проинтерпретировать неправильно.
Да, тоже интересный пример. Как я сказал в самом начале статьи, артикли — это самая сложная тема для нас. Я бы тоже в обоих случаях the использовал, но тоже не могу уверенно объяснить почему. Есть, кстати, похожая идиома, а еще книжка с таким названием.
Согласования артиклей, как мне кажется, не существует. Выбор от каждого конкретного существительного зависит.
Насчет the user, в документации он не абстрактный. Это как раз случай "объявленной" сущности. Даже если в тексте ни разу не встретилось a user, читатель понимает что речь идет о некоем одном и том же живом пользователе.
Кстати, полагаться на техническую документацию при проверке употребимости тех или иных норм языка нужно очень осторожно. Сперва убедитесь, что она написана грамотными носителями языка. Мой опыт технического переводчика говорит, что это в 80% случаев не так.
Это действительно довольно любопытный пример. Давайте разберемся.
В данном случае под man понимается не настоящий человек, а некий абстрактный собирательный образ человека. Поэтому ни a, ни the здесь не подходит. Я как-то поленился упомянуть про этот случай в статье, т.к. он нечасто на мой взгляд встречается в технических текстах, но если существительное используется в качестве абстрактного образа предмета, то артикль перед ним не ставится.
Лучше всего этот принцип проиллюстрировать на пицце:
I called for a pizza — Я заказал пиццу (какую-то одну, но какую не важно).
The pizza is still hot — Пицца (конкретная) еще горячая.
I like pizza — Я люблю пиццу (но не какую-то конкретную, а пиццу в целом, как явление).
В данном случае человек — это пицца :)
Теперь ко второй проблеме. Почему у абстрактного человека "конкретные" руки? Здесь я не вижу такого однозначного и простого ответа, но думаю, что здесь идёт противопоставление с руками Господа, которые абсолютно точно the, хотя они тоже абстрактны, ведь это выражение в переносном смысле, речь не идет о физическом падении в руки. И когда речь заходит о руках человека, то артикль показывает что эти "руки" используются в том же переносном смысле, что и при первом упоминании. Как-то так.
На тему артиклей есть еще одна хорошая иллюстрация, кстати.