Глоссарий перевода на Русский язык #36
Comments
|
В целом варианты ок, но есть небольшие имхо-комментарии
|
|
Не люблю кальки, если без них можно обойтись и уже есть устоявшийся русский термин. Поискал по переводам man-pages:
directory->директория = 0
В тексте Git встречася много раз. В выборе "блоб" vs "двоичный объект "- я за второй вариант. Опять же переводчики из Microsoft
Да, "отбор лучшего" не самый лучший вариант. "выборочное применение коммита" - хороший вариант, хоть и длинновато. Microsoft используют "выборочный отбор" - мне нравится такой вариант.
А как переводить feature branch тогда? "фичеветка"? Намного лучше "тематическая ветка", ИМХО. Еще есть вариант "возможность", но он тоже какой-то неоднозначный...
"кармашек" ну и правда смешно, так и представляю как суровые бородатые программисты на Си изменения "в кармашек прячут", чтобы не потерялись. А еще есть "shelve" в Mercurial - по логике выходит тогда "полочка"? :) Я предлагаю остановиться на безликом "отложенные изменения".
Дочерний модуль / репозиторий, вложенный модуль / репозиторий - многабукав, тем более есть возможность заменить меньшебукав. суб- - калька с английского, можно и без неё обойтись в этом случае без потери смысла, ИМХО. В MS используют "подмодуль". :)
Метка - она и есть метка. Вроде такой перевод и есть в глоссарии. В MSVS так вообще - "тег". Дело вкуса.
В этом случае я за любой перевод, лишь бы одинаково в было интерфейсе Git и в книге. В интерфейсе правда его объяснить не выйдет, потому нужно выбирать наиболее понятный.
Этот термин всегда в связке с fetch\pull\push (извлечь\получить\отправить изменения из репозитория). Немного обсуждали тут и тут - устоявшегося перевода нет. :( Нужно минимум букв - чтобы влезало в интерфейс (не думайте только о переводе книги). Пока предлагаю остановиться на том, что есть.
Тут еще используют перевод "обработчик". Microsoft тоже его предлагает Предлагаю со мной спорить. :) |
|
Не сочтите за оскорбление, но у вас есть своё мнение, или вы во всём полагаетесь на Microsoft? |
|
@madhead конечно, есть своё мнение. Но в Microsoft работают хорошие локализаторы - у них есть чему поучиться, глупо было бы не использовать их опыт. Тем более, это даст более однообразную терминологию. |
|
@DJm00n может и хорошие, но у нас есть шанс сделать лучше |
Спорно. Директория - нормальный академический перевод, ничуть не хуже каталога.
Вот поиск по оригиналу. В тексте встречается 8 раз, иногда рядом, и ещё несколько раз в коде (не переводим). И, кстати, что насчёт "многабукав" по поводу варианта переводчиков™ из Microsoft™?
"Отбор" - это когда я лучших коров плодится оставляю, а худших - на колбасу. И лучше бы Microsoft™ использовал этот самый отбор, набирая персонал.
Так и переводить - "тематическая ветка". Ну или "ветка для фичи", если не против многобуквенности. Это не вносит путаницы. А в случаях, когда слово "feature" используется самостоятельно, вполне допустимый перевод - "фича", ведь все привыкли.
Отличный вариант. Но он описывает не сам stash, а содержимое stash'а. Уверен, можно выкрутится будет в каждом отдельном случае. Кармашек - это на случай если вдруг захочется взбодрить читателя..
В этом есть смысл. Но имхо лучше "многобукав", чем некрасивое слово. Это книга. Её должно быть приятно читать.
Согласен, единого варианта нет. В каждом случае можно подобрать слово, подходящее по контексту.
Обработчик - это больше handler.
Общая претензия к "многабукав": это перевод книги, и тут нет проблем с тем, что текст не влезет в UI. Если на UI возникают какие-то проблемы - это проблемы локализации UI и решать их нужно там. Не стоит ограничивать перевод книги длиной кнопок в стороннем продукте. И уж тем более не проблема если в книге будут использоваться длинные составные термины, сокращённые в софте до единичных слов. |
ИМХО устаревший термин. Сейчас используют либо каталог (в случае directory) либо папка (folder). Могу также сослаться на Грамота.ру или Яндекс.словари :) Тут не принципиально - можно и так и так. Все поймут о чем речь.
Вроде как раз в этом и смысл cherry-pick - отбор лучшего коммита ветки.
полностью согласен, но "ветка для фичи" кривовато выглядит ИМХО.
ничего не имею против.
просто нужно попытаться сделать так, чтобы когда речь идет о терминах - перевод был однозначный и одинаковый в книге и в интерфейсе Git. конечно описать термин в книге можно как угодно и без ограничений на длину. |
|
По поводу fetch\pull\push.
Как вам? |
|
@DJm00n, текущий определённо лучше. |
|
По поводу cherry-pick, понял ваш консёрн. Перевод дословный, с учётом устоявшихся выражений, это хорошо. Но лично у меня при прочтении такого перевода возникает ощущение, что плохой коммит я черрипикнуть не могу. Возможно, это что-то из области психологии и восприятия фразеологизмов. Но при черрипикинге все коммиты равны )). Как-то так.
Безусловно. Согласны, что перевод слова "feature" как "фича" не обязывает переводить сочетание "feature branch" как "фичеветка"?
Если выбирать между "перехватчик" и "обработчик", то лучше уж перехватчик: типа "перехватчик отправки данных на сервер". Это ближе к реальности, потому что он не обрабатывает отправку, а лишь вызывается в процессе при отправке как побочный эффект.
Из такого перевода не видно разницы между fetch и pull. Лучше, в зависимости от контекста, уточнить, происходит лишь получение изменений, либо они ещё и сливаются с локальной репой. Разницу между fetch и pull очень сложно передать в одно слово. А на UI мне нравится как сделали в Git for Windows - "sync". Сразу понятно, что синхронизируется состояние реп (что примерно делает pull). Поэтому я бы выбрал (для интерфейса программы): fetch - "забрать изменения" / "получить изменения" / "узнать об изменениях" (корявенько, но ближе всего), а для pull - "синхронизировать репозиторий" (не дословно, но уже понятней, что эта операция чего-то поменяет локально). |
|
Надо определиться как писать слова вы, ваш, вас. С заглавной или строчной буквы. А то уже есть расхождения. |
|
@askras, в литературе и интернете (кроме личной почты) пишут «вы» с маленькой буквы. |
|
ок |
|
@DJm00n 👍 |
|
Встретился мне в переводе интерфейса (возможно, есть и в книге) термин trailer - обозначают так заголовки Signed-off-by и т.д. в конце сообщения коммита. В общем похожи эти заголовки на заголовки в email, но идут в конце сообщения.
Ваши варианты? |
|
В файле 01-introduction/sections/basics.asc .... Git имеет три основных состояния, в которых могут находиться ваши файлы: committed, modified и staged. Committed означает, ...... Может быть переводить как в первой версии .... В Git'е файлы могут находиться в одном из трёх состояний: зафиксированном, изменённом и подготовленном. "Зафиксированный" значит..... или так ... В Git'е файлы могут находиться в одном из трёх состояний: зафиксированном (committed), изменённом (modified) и подготовленном (staged). "Зафиксированный" значит... |
|
@askras, ИМХО 3й вариант предпочтительный. |
|
Вот и мне он больше нравится |
|
commit – фиксация |
|
@sadfuzzy, теперь везде менять коммит на фиксацию? "коммит" (как существительное) в разы привычней слуху. Я не против "to commit" -> "[за]фиксировать". |
|
Я в переводе интерфейса использую и тот, и тот перевод. Иначе как-то не читабельно выходит "фиксация" как существительное. |
|
@DJm00n, +1 |
|
Просто книгу хотят взять в печать и просили не простой транслитерацией переводить |
|
Поискал по всем своим "источникам", и оказалось, что везде используют слово "фиксация": |
|
@DJm00n та же ерунда :( Хотел бы я увидеть разработчика, который говорит "фиксация" |
|
Крутые ссылки, спасибо. Ну сленг на то и сленг, чтобы быть нелитературно удобным :) |
|
Не, ребят, это реально печалька |
|
@Dobrosvet, в английском языке многие глаголы звучат и пишутся так же, как и существительные. Так работает язык. Пример из русского: «Добро побеждает зло». Как это ни странно, «зло» здесь может быть не только существительным в винительном падеже, но и наречием (добро побеждает как? зло). |
|
@Menelion, хорошо а нам что нужно? Нам нужно понимание английского для изучения Git? Изначально да, так как источник на английском, а после перевода? Английский уже не нужен. И нужно понимание вещей (зачем мы делаем "git commit" и что из него получается). В чём проблема писать то же слово "зафиксировать" или "закрепить", а не "делать коммит", и писать "снимок" вместо "коммит"? Они понятны без переводчика и дополнительных источников. |
|
@Dobrosvet, мы не можем писать «снимок» вместо «коммит», потому что снимок — это snapshot. В техническом переводе (да и любом специализированном) есть принцип единства соответствия терминологии. Мы не можем называть две вещи одним русским словом, иначе получится чудовищная путаница. Я долго носом рыл этот вопрос, иногда к нему до сих пор возвращаюсь, но пока мой вердикт прежний: для слова «commit» как существительного адекватного перевода на русский нет. Это не единственное такое слово: например, в некоторых языках есть понятие an iterable. На русский это переводят как «итерируемый объект» — длинно и некрасиво, но ничего лучшего нет. Так и тут с коммитом. Может быть, кто-то ещё выскажется. |
Вообще говоря, слово "снимок" не отражает тот факт, что у commit'а есть parent commit. Снимок может отражать смысл "состояние файлов на момент X", но коммит это больше, чем просто состояние файлов.
А чего поделать? Вариант "слушай, Вась, у ты во вчерашней фиксации не перепутал названия переменных?" звучит уж очень странно. Ни от кого не слышал такого. Более того, слово "фиксировать" (to commit) созвучно с общеупотребимым "фиксить" (to fix), что может вводить в заблуждение при обсуждении "фиксации" и "фикса".
О, точно. Почему же мы делаем |
|
@Dobrosvet, да, «закрепить» нормальный вариант…был бы^ если бы уже не существовало устоявшегося термина. Нормальный, не лучше других. Сообщество выбрало устоявшийся вариант (хоть и жаргонизм, но всем понятный). Демократия, все дела. |
|
@Menelion, так уже путаница... Я понял вас, значит в английской версии идёт только сравнение коммита со снимком и англоговорящие не говорят snapshot, а только commit? @vlsi, а что мешает подписать сзади снимок сделав ссылку на предыдущий скажем по дате, описанию или по идентификатору написанному на задней стороне?
По этому я не за фиксацию.
Сравните два варианта. Человеку который вообще только пришел в программирование, какой вариант будет легче объяснить? Он спросит что такое коммит(у него нет НИКАКИХ ассоциаций), а вы ему скажете что это похоже на снимок кода, (ассоциации: это похоже на фотографию, только кода, момент который не изменить, ...), более того окружающие люди скорее всего поймут что вы говорите не о фотографии а о коде, но почему то говорите про снимки, и у человека всплывут те же ассоциации он хоть что-то поймёт, не знакомый с программированием. И ничего не странно, отлично звучит. А "коммит" значит изначально для вас не странно?
Ну это простите, бред, если бы изначально было "a fix" - исправление, и "to fix" - исправлять. Тогда бы не пришлось их сравнивать. Не говорите фиксить в таком случае, и исправляйте всех от кого это услышите. Уж извините если я и тут не прав я умываю руки, я не понимаю тогда ни людей, ни почему старшее поколение оставило нам столько сложностей, ни как их преодолевать, разбираясь в этой каше.
Я вас понял, но вы не прочитали мой предыдущий комментарий.
Вот это странно. @DJm00n, сообщество проголосовало за варианты одного человека. Я не вижу там вариант "закрепить" и других которые предлагали в комментариях, их дополнительно не посчитали (типичная Демократия). Хотя я не сомневаюсь что результат бы изменился. Основной аргумент за "коммит" это, "привык, по этому понятнее, оставьте так", хорошо а что делать тем кто "не привык и не понятно", правильно!, выражусь цитатой @Menelion
Нам остаётся рыть носом ошибки предшественников, а не решать руками свои задачи. "Коммит" и "коммитить" неприемлемые слова и их однозначно нужно заменять. Но я не вижу ни оного голоса поддержки, по этому похоже это останется только моим мнением... |
Посоветовать потратить часик на расширение словарного запаса. Потом пригодится. Почему всё должно быть удобно вам лично? Вся индустрия использует слова "коммит", "фиксить", и ещё пару сотен, если не тысяч, подобных.
Сложности будут у вас когда вы со своим словарём решите пообщаться с кем-нибудь, скажем, на конференции. Кстати, как вы относитесь к латинскому слову "конференция"? Не лучше ли нам говорить "сборище"? А то как-то ну... знаете... если человек ни разу не был на конференции, не совсем понятно что имеется в виду... |
Да в том-то и дело, что человек, далёкий от программирования, простите, не коммитит. Зачастую, работа таких инженеров сопряжена с нетекстовыми средами. Например: Word, Excel, Apache JMeter, Owen Logic. В этом случае, git diff/merge не даёт никаких плюсов. Там бинарные форматы хранения. Вот и получается, что "далёкие ассоциации" нужны только тем, кто этим самым иснтрументом пользоваться не будет. Да, возможно, есть ненулевое количество тех, кто "не понимает что такое коммит", но при этом "получит реальную пользу от использования git". А тем, кто разбирается в программировании, проблем понять "кто такой коммит" и чем он отличается "от слепка состояния дерева файлов" никаких нет. Не хочу никого обижать, но "корявые" переводы "общепринятых" слов крайне и крайне мешают в работе рядового программиста. Вот выше было обсуждение перевода "cherry-pick vs отбор лучшего". Это же дичь какая-то. Я когда увидел "отбор лучшего", то вообще пользоваться не смог. Так и с коммитом. Я не вижу смысла делать "далёкую ассоциацию" для привлечения 10 новых пользователей, и при этом обращения 100500 программистов в шок. Делать 2 варианта перевода (git-русский-с-заимствованными и git-русский-вообще-без-заимствованных-слов), наверное, было бы совсем странно.
Тут ваша ассоциация не различает разницу между "состоянием дерева файлов" и "коммитом".
Для меня "коммит" в смысле существительного звучит гораздо лучше чем "снимок" (который ассоциируется с разнообразными snapshot'ами файловых систем гораздо больше чем с фотоснимками). Более того, "коммит" как существительное для меня звучит гораздо менее жаргонно, чем "фиксить баги". Вот "коммитить" звучит более жаргонно, и я предпочитаю варианты "зафиксировать изменения" / "вчерашний коммит".
Простите, но от выражения "баги фиксить" мы вряд ли уйдём, даже если будем стараться искоренить подобное. Я не о том, что нужно стараться "фиксить баги", а о том, что этот жаргон слишком широко распространился. |
|
Коммит, существительное которое вы имеете в виду, тоже самое что и snapshot в английской версии учебника по смыслу, это одна сущность? |
Нет, это разные сущности и эти слова имеют разную смысловую окраску. Коммит (сущ) это commit (сущ). Английская версия различает слова snapshot и commit. Или же фраза Git is fundamentally a linked list of commit objects that point to a snapshot of content |
|
@Dobrosvet, об этом мы вам и пытаемся сказать с Владимиром: commit и snapshot — совершенно разные вещи, поэтому перевод «снимок» для коммита ну никак не подходит. Я полностью поддерживаю Владимира: «зафиксировать изменения», но «вчерашний коммит». Это асимметрия заимствований в языке и это нормально. Мы заимствовали computer, но не заимствовали to compute, например. |
|
@madhead, вы не поняли, не лично мне.
Что так, что не так? |
Так скажите, каким словом вы собираетесь заменить слово коммит, тогда и поговорим. Например, так: Вот чем вы предлагаете заменить слово коммит?
Это вы так перевели фразу "Git is fundamentally a linked list of commit objects that point to a snapshot of content"?
Т.е. у вас два разных определения для понятия "снимок". В одном (2) это просто содержимое файлов, а в другом (7), это содержимое файлов + то, как к этому состоянию пришли.
Отчего же? Как вы назовёте результат выполнения Пункты 8-11 вообще относятся к деталям реализации, и они не могут (не должны) использоваться для описания базовых понятий. Git может хранить как файл целиком, так и разницу от предыдущей версии в зависимости от того, какая форма более компактна. Для конечного пользователя это скрыто. Поэтому обсуждать "хранит ли snapshot файлы целиком или в виде diff'ов" смысла нет. |
|
Пункты 2 и 7 считайте одним предложением это одно определение а не 2 разных. Я вообще задал вопрос, а вы отвечаете вопросом, тем более к новичку и просите меня объяснить вам чем я хочу заменить. Ответ "Я хотел заменить на снимок", но @Menelion объяснил что этого сделать нельзя, так как в них разный смысл. Вопрос уже не в том что бы заменить, а что бы понять.
В результате этой беседы уже вроде всем понятно, и уже даже мне понятно, что я не знаю что такое коммит (хотя и делаю их периодически). Так объясните русскими словами что такое коммит что бы я понял что это такое, а потом я вам скажу слово которым его заменить и вот тогда уже и поговорим. Я пытаюсь прочитать учебник и хочу понять в чём смысл. Но там не написано "коммит это - ", там написано
Тут есть слово "коммит". "Когда вы делаете коммит" эта фраза абсолютно непонятна, до этого слово никак не определено. А дальше оно вроде как определено после запятой, его определение "состояние", но до этого было
Чувствуете? "коммит - состояние", "снимок - состояние" и получается что "снимок - коммит" Что такое коммит? |
Глава: 10.2 Git изнутри - Объекты Git объясняет это, хоть и мудрёно. |
|
@DJm00n, спасибо. Там написано что коммит это зафиксированные данные. В первом же его употреблении. |
Ну, мои пункты а..д как раз про описательную часть того, что из себя представляют коммит и снимок. Предлагаю такие варианты (это не кандидаты на перевод, а просто попытка объяснить смысл слов):
Смысл простой. Снимок файлов тут означает "в файле hello.txt хранится строка Рассмотрим, например: Глядя на одни только "состояния" невозможно понять какова была история развития проекта. Невозможно даже "просто" понять какое сейчас самое последнее состояние (т.к. сами по себе состояния никак не упорядочены). И тут на поле выходят коммиты. Коммит описывает следующее: Заметьте, в коммите не просто "предыдущее состояние", а именно ссылка на "предыдущий" коммит (parent commit). Если бы в коммите было просто 2 ссылки на "текущее Именно по коммитам можно понять "какое состояние файлов" актуально сейчас, какое было вчера и т.п. Сами по себе "состояния файлов" не упорядочены, а коммиты задают частичный порядок истории репозитория. |
|
@vlsi, вы даже отметили что вам не нравится предыдущий мой комментарий, как будто в книге упомянутой @DJm00n нету утверждения что коммит это зафиксированные данные. Или как будто я сказал "Всё утверждаем этот вариант". Это не так. Я просто указал на факт. А мне не нравится что вы хотите оставить Воооот, теперь понятнее, спасибо.
Так же выглядит хорошо, это уже не И это тоже выглядит лучше
Предлагаю. |
Я ту книгу не читал, но осуждаю. В этой книге уже был перевод "отбор лучшего" для операции "cherry-pick" #36 (comment).
Слово коммит же отражает смысл, что "коммиты упорядочивают историю развития проекта". |
|
А тут крайне не удачный перевод Что это за аргумент "общее"? Ключ тоже общее понятие, он много чего значит, но никто не говорит электронный
Не понял фразы
Какой она должна отражать в случае коммита? Ей это не под силу в отличии от коммита? почему? |
Имел ввиду, что В этом ключе слово
Слово Есть пример из области "как называть снег".
Вот вы пойдите к эскимосам и объясните им, что все их слова лишние, и достаточно одного слова "снег". Так и со словами |
Вот как раз в этом и дело, что такой тип записей в Git называется коммитами. |
С коммитами всё по-другому. В Git есть много разных типов записей. Все типы используются в рамках одной книги, и многие типы записей используются в одном предложении одновременно. Вспомните, например, такое:
Путаницы между дверным и скрипичным не возникает, т.к. обычно они не используются в одном предложении (да и в рамках одной статьи они нечасто используются вместе). |
|
Путаницы вроде нет, даже никаких дополнительных уточнений я не использовал и всё в одном предложении. |
|
@Dobrosvet вы сетуете, что Git не адаптирован для того, чтобы его осваивали новички. Действительно, не адаптирован, а ещё и просто сложен. И языки программирования сложны, и всё остальное в IT достаточно сложное. Можно пойти дальше: строительство — сопромат, право — кучи законов и юридический язык, в космос полететь — надо на центрифуге тренироваться. Везде сложно, а причина этого проста. Инструменты делаются не для того, чтобы их осваивали новички. Они делаются, чтобы решать ими задачи реального мира. А реальный мир сложный, потому и инструменты сложные. Пока что вы изучили основы Git. Вам сейчас кажется, что вы лучше всех понимаете, как всё должно быть устроено. Когда вы изучите ещё сколько-то — поймёте, почему всё устроено именно так. Это похоже на эффект Даннинга-Крюгера. Термин «коммит» уже знают и используют сотни тысяч русскоязычных инженеров. Вы не сможете поменять их привычки и никто не сможет. Если в книге или переводе интерфейса использовать другой термин, то эта книга и интерфейс только вызовут раздражение. Насильно мил не будешь. Перевод «коммит» выбрали не вам назло. Его выбрали, чтобы не мешать работать людям, которые уже к нему привыкли. Им и без этого сложно работать. |
|
@NickVolynkin, я не понимаю меня вообще никто не воспринимает что ли, нет я понял я ни слова больше не скажу, только отвечу на ваш комментарий.
Не верно, по тому что я не говорю "Адаптируйте Git для новичков, что бы им было легче", я не прошу адаптировать Git я прошу адаптировать слово одно лишь слово, которое составляет основу для изучения Git. Я утвержадаю что слово
Да откуда вы это вообще берёте. Я ничего вообще, ничего в своей жизни не знаю лучше других, буквально! Я аутсайдер по тому что не понимаю как жить в этом мире, и даже на просьбу, я подчёркиваю ПРОСЬБУ и предлжение, такая реакция. Я не под вашим эфектом, я под вашим непонятно откуда взявшимся, выводом что я знаю что то лучше всех.
Они РАБОТАЮТ они не читают книги по основам с которыми они уже работают и знают, иначе они бы не работали Я пытаюсь учится, а вы пытаетесь не научить а унизить, спасибо за поддержку. |
@Dobrosvet , пока же всё выглядит так, что вы пришли в автошколу и предложили говорить вместо Представляете себе реакцию водителей, если предложить во всех инструкциях вместо слова Может, попробуете слово По факту, да, чтобы предлагать, нужно разбираться в области. Если вы только пару раз пощупали слона, то это не повод просить авторов книг о внесении изменений в терминологию. Сначала вы предлагаете переводить commit словом закрепить Ладно, если бы вы как-то реагировали, но вам же уже сказали почему варианты не подходят.
Язык развивается, и вполне может быть, что в очередную редакцию "словаря Ожегова" (или куда там) добавят слово "коммит (сущ.) -- ..." |
|
Коллеги, я в очередной раз прохожусь по первой части, сравнивая с английской версией и синхронизируя, где надо. |
|
Да, похоже, что "распределённая" правильнее. |
Предлагаю всё же обсудить и принять общие переводы терминов.
На данный момент есть:
За основу предлагаю взять 2й вариант и в случае изменения перевода термина — изменять и там тоже т.к. этот перевод войдет в официальный Git как будет готов.
Возражения/пожелания/идеи?
The text was updated successfully, but these errors were encountered: