Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Обсуждение словаря терминов Laravel.
Вносить изменения нужно с помощью коммитов здесь.
А спорные моменты давайте обсуждать в этой ветке.
Изменено AlexeyMezenin (05.05.2016 09:17:45)
Не в сети
Мастер 
О, надо же, кто-то тоже считает, что «рунглиш» это не «маст хэв». Помню, когда я переводил документацию 3 и 4 веток меня обвиняли в том, что я использую непонятные и нераспространённые слова.
Сейчас в документации на этом сайте используются такие термины:
Не в сети
Мастер Не в сети
}%Алексей, может хочешь написать статью на главную? Вверху кнопка.
Статью обязательно напишу. Только сначала пополнее нужно словарь заполнить. Завтра сделаю коммит для твоих вариантов, на будущее, делай пожалуйста сразу на GitHub мелкие правки, а я буду первый пост здесь обновлять. Так и другие разработчики подтянутся. В итоге словарь будет более качественным.
Не в сети
Мастер Не в сети
А все понял, раз там md, сделаю в виде статьи. Про три колонки услышал. Завтра займусь.
Не в сети
Proger_XP, есть спорные моменты.
Это всего лишь мое мнение, я вовсе не претендую на правильность. Цель здесь - собрать переводы терминов, которые бы устроили все сообщество, поэтому хотелось бы услышать мнение как можно большего числа разработчиков, чтобы определиться с окончательными вариантами:
authentication - авторизация || аутентификация - это не одно и то же - http://www.cyberciti.biz/faq/authentica … orization/
cookie - куки или cookie - рунглиш, но мне кажется куки уже состоявшееся слово, как кэш, например
firing event - очень понравился вариант "инициация", мне кажется он наиболее близок по смыслу с оригиналом
helper — в контексте «helper methods/functions» — просто функции, либо полезные функции || мне кажется нужно как-то отделить понятия function и helpers, слово очень часто встречается в вопросах, важно передать точный смысл
hook - сложный случай, давай послушаем еще людей, чтобы определиться с конечным вариантом
pagination — страничный вывод || постраничный вывод || пагинация - пагинация тоже вполне устоявшееся слово, не раз встречал в переводах документации к различному ПО
resource controller - контроллер ресурсов || ресурсный/ресурсовый - если честно, не один вариант не нравится, пока не знаю как красиво перевести
serialization — упаковка || сериализация - мне нравится устоявшееся слово сериализация (и десериализация) - такой перевод в Wiki, PHP документации, JS документации. Упаковка меня лично сбивает с толку. Послушаем еще мнения.
service container, ioc — сёрвис-контейнер - рунглиш - его называют просто контейнером в оф. документации.
stack — стёк, но в контексте веба скорее дословно — пачка (batch), стопка - вообще не знаю как здесь, возможно лучше "стек"? Или еще как-то?
validation — проверка (ввода) || валидация тоже вполне устоявшийся термин, не только в программировании
billing — оплата, финансы || биллинг - последнее устоялось и четко передает суть
normalize — очистить, привести к стандартной форме/общему виду и пр. || может лучше "нормализация"? Устоявшееся слово во многих индустриях
Не в сети
Proger_XP, статью оформил, ссылки сделал. Markdown в статье почему-то не видит тэги ~~ (зачеркнутый текст), возможно это исправить?
Сделал три колонки, сортировка по оригинальному названию. Все верно? Или имелись ввиду другие колонки (таблица или еще что-то)?
Не в сети
Мастер
- Proger_XP, есть спорные моменты.
Я тоже выразил своё мнение, так что не претендую на его непогрешимость. Кто переводит тот и решает, какие слова использовать, кто читает — тоже решает, какой стиль ему больше нравится.
- authentication — авторизация || аутентификация — это не одно и то же
Верно, просто в русском второй непривычен (на мой взгляд), хотя против «аутентификации» ничего не имею.
- мне кажется нужно как-то отделить понятия function и helpers, слово очень часто встречается в вопросах, важно передать точный смысл
- hook — сложный случай, давай послушаем еще людей, чтобы определиться с конечным вариантом
Hook вообще сам по себе используется в двух формах, поэтому одним словом здесь не обойтись. Отслеживание событий — hook an event/add event handler. Точка для отслеживания — event hook (это может также быть «отслеживатель/слушатель» как в «this is that event hook»).
- пагинация — пагинация тоже вполне устоявшееся слово, не раз встречал в переводах документации к различному ПО
Не знаю, меня «пагинация» просто с ума сводит. Если ещё cookie/куки можно понять, то здесь-то почему не использовать русские слова?
- resource controller — контроллер ресурсов || ресурсный/ресурсовый — если честно, не один вариант не нравится, пока не знаю как красиво перевести
Оба слова непереводимы, новых вариантов не придумаешь. «Ресурсовый» — я такого слова даже не знаю.
- мне нравится устоявшееся слово сериализация (и десериализация) — такой перевод в Wiki, PHP документации, JS документации. Упаковка меня лично сбивает с толку.
«Упаковка» короче, но я сам часто использую «сериализация», т.к. действительно устоявшийся термин.
В Java есть термины boxing/unboxing, они тоже переводятся как «упаковка» — это не то же самое, что «сериализация».
- service container, ioc — сёрвис-контейнер — рунглиш — его называют просто контейнером в оф. документации.
IoC это IoC, не переводится, но когда говорится service container, то тут стоит всё-таки уточнять, контейнер чего именно.
- вообще не знаю как здесь, возможно лучше «стек»? Или еще как-то?
Про какой контекст мы говорим? Если в контексте механизма хранения значений (очереди, деревья и пр.) — то это пачка или стопка, т.к. мы не говорим «кью» или «три» из-за того, что queue и tree (и stack) это вполне физические понятия, которые можно перевести однозначно без потери смысла.
Если в контексте модели памяти в приложениях, то стёк это устоявшийся термин («на вершине стёка», «объекты создаются в стёке»). Забавно, кстати, что наравне со «стёком», который не переводится, в этой же сфере есть термин heap, как в heap memory, который переводится как «куча» («строка в куче»).
- валидация тоже вполне устоявшийся термин, не только в программировании
- может лучше «нормализация»? Устоявшееся слово во многих индустриях
Тоже зависит от контекста. В БД нормализация это совершенно иное, чем «нормализация», которая используется в том же контексте, что и validation/проверка ввода, поэтому чтобы не путаться я его не использую.
- Markdown в статье почему-то не видит тэги ~~ (зачеркнутый текст), возможно это исправить?
Странно, вроде бы должен работать. Пока используй <s>, я потом посмотрю (библиотека для форматирования не моя).
- Сделал три колонки, сортировка по оригинальному названию.
Не вижу трёх колонок, вижу список. Я имел в виду таблицу с 3 колонками:
Кстати, ещё термины на обсуждение:
Не в сети
Мастер
- Неплохой, на мой взгляд, альтернативой данному словарю может быть использование оригинальных терминов на английском (route, action, IoC).
Не надо путать имена собственные (названия), аббревиатуры, термины и нормальные английские слова. Название — это Artisan, аббревиатура — IoC, термин — stack, слово — route.
Названия не переводятся, либо пишутся транслитом, если нет устоявшихся исторических имён уже в самом языке (к программированию это не относится) — города «Москва» = «Moscow» (историческое имя), аэропорт «Шереметьево» = «Sheremetyevo» (транслит). Транслит лично мне не нравится (если читатель знаком с алфавитом), он сложнее читается и пишется, так что вместо «Артизан» я использую «Artisan». Как приятный бонус — по правилам русского языка все названия надо выделять кавычками, но если они в оригинале их можно не выделять (т.е. по правилам всё равно нужно, но из-за другого алфавита они и так выделяются в тексте).
Аббревиатуры надо переводить, т.е. если IoC это «обратный контроль», то тогда IoC = ОК. ИМХО, в программировании люди английских букв не пугаются, для простоты лучше оставлять как в оригинале, особенно когда распространённых переводов нет, как у CPU/ЦП. Люди будут искать «ОК» и ничего не найдут, а IoC — сразу.
Термины сложный момент, их надо как-то переводить, т.к. это часть текста и их надо склонять и вообще, если не переводить термины, то тогда можно и текст оставить в оригинале, т.к. он из них состоит.
Ну, а слова надо переводить однозначно, благо для них есть соответствия в языке и/или переводы уже были придуманы, т.к. слова не специфичны конкретно для программирования или другой сферы, где делается перевод.
Так что сложность в том, чтобы определить, что есть слово, а что термин, а для терминов — какой адекватный перевод можно использовать.
Не в сети
Вроде неплохо (закоммитишь?):
- helpers - вспомогательные функции
Остальное, я тоже не знаю как здесь перевести лучше, давай мнения подождем, не торопимся ведь )
1. Hook - не идеал, да
2. «пагинация» просто с ума сводит
3. resource controller
4. Stack - здесь вообще не знаю как переводить
«Упаковка» короче, но здесь нужно перевести так, чтобы сомнения не оставалось о чем идет речь, т.е. чтобы не было людей кто бы думал "а что за упаковка?".
Не вижу трёх колонок, вижу список. Я имел в виду таблицу с 3 колонками
А как сделать таблицу в markdown? Не нашел тэгов для этого.
Кстати, ещё термины на обсуждение
Закоммить пожалуйста отдельно (кстати, "коммит" бы тоже перевести).
Изменено AlexeyMezenin (05.05.2016 09:32:24)
Не в сети
Не надо путать имена собственные (названия), аббревиатуры, термины и нормальные английские слова. Название — это Artisan, аббревиатура — IoC, термин — stack, слово — route.
Я имел ввиду нечто подобное, как альтернативу:
"Я создал route и направил его в action, но он не работает...".
Есть те, кто всю литературу читают только на английском и порой хочется выразиться точно. Учитывая то, что литературы по Laravel на русском нет, таких, наверное, большинство. Я не говорю, что это лучший вариант, но на мой взгляд это несравнимо лучше рунглиша и отсебятины. По крайней мере при таком варианте все сразу поймут о чем идет речь, поэтому предлагаю не пинать тех, кто позволяет себе так писать. 
Да, URL прописал везде короткий, так действительно лучше, спасибо.
Тэги <s> давай тогда сделаю, когда словарь более менее устоится.
Изменено AlexeyMezenin (05.05.2016 09:34:17)
Не в сети
Мастер
- «пагинация» просто с ума сводит
Где ты видел «пагинацию» в старых текстах?
- А как сделать таблицу в markdown? Не нашел тэгов для этого.
Видимо в этой библиотеке их нет, хотя в GFM они есть. Есть идея, потом переформатирую твою статью.
- Закоммить пожалуйста отдельно (кстати, «коммит» бы тоже перевести).
Сегодня пришлю pull request (вот, кстати, хороший пример, когда можно не переводить).
А «commit» переводится как фиксация (изменений). По-моему я видел это в старой книжке по Subversion. Вполне нормально звучит.
- Я не говорю, что это лучший вариант, но на мой взгляд это несравнимо лучше рунглиша и отсебятины.
Это верно, но это не идеальный вариант:
Обычно, когда переводят текст с терминами, которые человек может не знать, пишут как-то так:
- Я создал маршрут (англ. route — путь, маршрут) и направил его на действие (англ. action), […]
Скобки иногда выносят в сноски. В этом случае получаем лучшее из двух миров — человек учится английскому и в то же время русский язык не страдает, а скорее обогощается новыми смыслами.
В 2000х и раньше, помню, книги по разработке пытались именно переводить, то есть искать соответствия терминов в языке, а не просто приспосабливая английские слова. Вот, например, как перевести Explorer? Проводник. А если это Internet Explorer? Обозреватель! По-моему гениально. Потом это забросили, стало не модно (поэтому я скептически отношусь к тому, когда ты говоришь, что «это уже вполне устоявшийся термин»).
Rак видно по File Explorer-Internet Explorer, в нашем языке одно слово переводится сильно по-разному в разных контекстах, в отличии от английского, который по своей натуре спокойно переносит даже смену части речи слов (типа monitor/to monitor, guide/to guide). Это ответ на «hook».
- По крайней мере при таком варианте все сразу поймут о чем идет речь, поэтому предлагаю не пинать тех, кто позволяет себе так писать. smile
Да, кстати, ещё надо разделять, о каком тексте идёт речь. Когда это форум/чат — тут понятно, каждый пишет как угодно, т.к. нет смысла особо думать над каждым термином. Если это документация или книга или другой массовый материал — вот тут нужно думать. Собственно, в этой теме я говорю только о последнем случае.
Не в сети
Видимо в этой библиотеке их нет, хотя в GFM они есть. Есть идея, потом переформатирую твою статью.
Хорошо, лишь бы копировать потом удобно было с GitHub.
Не в сети
Мастер Сделал форк для pull request, но заметил, что некоторые термины (validation) у тебя свои, так что будет лучше, если ты сам будешь вносить изменения, как считаешь нужным. Я не со всем согласен, поэтому либо надо всё редактировать, либо ничего.
Вот мои варианты, в добавление к уже сказанному:
Не в сети
Внес изменения. Ты можешь коммитить по одной фразе. ) Все равно это удобнее, особенно если люди еще подтянутся.
Спорные моменты:
* framework - фреймворк --- каркас мне кажется не к месту, никто не поймет что за каркас )
* pattern - оставил только "шаблон", потому что используется в разных контекстах и иногда маска не к месту
* checkout - по смыслу здесь близко "выписать", ты как-бы "выписываешь" себе на машину определенную версию кода, но как-то криво звучит, ничего не стал вписывать, просто добавил пустое поле пока
* diff - команда, мне кажется переводить не нужно, потому что если скажешь кому-то "различия", то с командой "diff", мне кажется, ассоциации не будет
* marshal - вообще не слышал, будешь уверен с переводом, добавлю твой вариант
* closure - отделил, потому что не одно и то же
Остальное внес как есть, спасибо.
Изменено AlexeyMezenin (09.05.2016 10:14:34)
Не в сети
Мастер
- Ты можешь коммитить по одной фразе. )
Только если после обсуждения, иначе ты потом будешь их сам менять, смысл делать двойную работу.
- framework — фреймворк
каркас мне кажется не к месту, никто не поймет что за каркас )
Это зависит от контекста: есть «каркас» приложения, как в «архитектура/структура приложения», а есть «каркас» как библиотека — фреймворк. В английском это одно и то же: «my app this kind of framework» vs «Laravel’s the framework that my app uses».
В первом случае переводить это как «моё приложение имеет такой фреймворк» как-то странно, лучше заменять на «структура» или «каркас» («каркас» непривычен, согласен, но структура — вполне).
- pattern — оставил только «шаблон», потому что используется в разных контекстах и иногда маска не к месту
Опять же зависит от контекста. Есть «search pattern», здесь нужно уточнять — а что за «шаблон»? Можно перевести как маска, смысл сохранится. Есть «design pattern» — здесь «шаблон», однозначно.
- checkout — по смыслу здесь близко «выписать», ты как-бы «выписываешь» себе на машину
ИМХО, звучит просто непривычно, а не криво. Смысл слова у «выписывать» практически идентичен.
- diff — команда, мне кажется переводить не нужно, потому что если скажешь кому-то «различия», то с командой «diff», мне кажется, ассоциации не будет
Опять контекст. «Let’s look at this diff» vs «diff as a menu command». В первом случае diff это просто различия, результат(ы) сравнения (файлов). Во втором — команда, которую я лично бы перевёл как «сравнить (файлы)».
- marshal — вообще не слышал, будешь уверен с переводом, добавлю твой вариант
Ну, как не слышал, он используется в Java и Net.
У них есть некоторое различие, наподобие с authorize/authenticate, но если бы я переводил это, то не стал бы мудрить и всё перевёл как «сериализовать», за исключением текстов, где действительно имеет смысл явно различать два термина. Различие.
В пользу этого говорит ещё занятный пример из документации Python, где сам механизм называется «marshal», а страница озаглавлена marshal — Internal Python object serialization.
Не в сети
Добавил некоторые.
asset - актив может? Или не звучит?
release - "релиз" в ходу, поставил выпуск со знаком вопроса.
production - "продакшн" с 90х в мозгах укоренилось, даже компании давно так называют, в отечественной киноиндустрии (если ее можно так назвать), опять же термин используется. Или может "производство"? Мол, "развернуть в производство".
staging - не стал переводить, лучше подождать получше вариант.
trait - типаж, знаю, что так переводят, но "трейт" мне кажется уже давно в ходу, в том числе в литературе. Пока не стал никак переводить, просто добавил.
mixin - "примесь" оставил, но вроде как в литературе так и пишут "миксин".
Не в сети
Мастер
- asset — актив может? Или не звучит?
У меня «актив» ассоциируется с фирмами. Asset, resource в контексте веба это одно и то же — стили, скрипты, картинки (ещё это называют «[multi]media files»).
- в отечественной киноиндустрии
Это другая область, там «продакшн» это скорее просто калька с «XYZ productions» в английском. А в вебе production это часть связки local (develop) — testing — staging — production. Другой смысл.
- Или может «производство»? Мол, «развернуть в производство».
- production — «production» или «производственный» (in production)
- deploy, roll out — развернуть, выкатить (на производство — in production) (взаимозаменяемо)
Интересно, кстати, в связи с кино в Википедии есть статья Постпроизводство, где говорится:
- Постпроизводство, также используется англицизм постпродакшен
Судя по всему, оба термина в ходу, не вижу, зачем нам использовать англицизм.
- но «трейт» мне кажется уже давно в ходу
ИМХО, этот термин широко стал использоваться только с PHP 5.4, а это относительно недавно. Как склонять «трейт»? «Трейтом», «трейты»? А может это вообще «треит»?
- mixin — «примесь» оставил, но вроде как в литературе так и пишут «миксин».
Это в какой, например? Опять же, Википедия.
Не в сети
Мастер Не в сети
}%Кстати, я вот думаю: стоит расширить словарь до glossary? Т.е. кроме просто перевода дать ещё краткое, на пару слов определение этих терминов, со ссылками в документацию или ВП.
Тогда URL поменяем на laravel.ru/glossary.
Внес новые слова, какие-то из них уже были. Расширять думаю не стоит, интереса у людей нет к словарю. Ссылки на документацию там уже есть где-то, можно добавлять.
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)
Писарь