Re: [RFR] po://apt/po/ru.po
В письме от пятница, 13 апреля 2018 г. 20:50:51 MSK пользователь Lev Lamberov
написал:
> Я бы перевёл буквально "Дубликат файла настройки %s/%s".
Проблема в том, что если смотреть в словарях, дубликат - это копия исходного
объекта, а тут речь идёт о файле с тем же именем, но наверняка иным
содержимым. Более близким к смыслу был бы перевод "Попытка перезаписать файл
настройки %s/%s".
Но раз в оригинале так, то пусть будет "дубликат".
> >> > "Пропускается получение настроенного файла «%s», так как репозиторий
> >> > «%s» его не содержит (возможно, репозиторий указан с ошибкой в
> >> > sources.list?)"
> >>
> >> "не содержит" -> "не предоставляет"?
> >
> > Разве здесь это не то же самое?
>
> В целом, да. Или может изменить подлежащее, чтбы не репозиторий был
> главным, а файл? Что-то вроде "так как он отсутствует в репозитории".
Этот вариант смущает меня слишком близким расположением слов "репозиторий", а
также нарушением системы с другими подобными сообщениями.
Пожалуй, тогда остановлюсь на "не предоставляет". Идёт?
> Да, не выпускается, но это и не дистрибутив в смысле классических
> дистрибутивов. То есть, unstable или sid не является выпуском в строгом
> смысле слова (это же указано и в вики [wiki]: "is not strictly a
> release"). Тем не менее, остальные-то являются выпусками. Конечно, даже
> в документации на английском языке эти термины иногда путаются, но я бы
> их развёл.
>
> [wiki] https://wiki.debian.org/DebianUnstable#Introduction
Да с этими понятиями вообще путаница ещё та. У того же apt-get есть опция --
target-*release*, аргументом которой может быть и experimental, который вообще
не выпуск и не дистрибутив. В Debian Handbook на русском вовсю используется
дословный перевод:
> Если вам это не требуется, используйте настройку APT::Default-Release
> (смотри Раздел 6.2.3, «Обновление системы»), чтобы сообщить APT о
> необходимости брать пакеты из другого *дистрибутива* (наиболее вероятно
> Testing в данном случае).
> Чтобы apt искал обновлённые версии пакетов для определённого дистрибутива,
> используйте опцию -t или --target-release. После опции надо указать
> название выбранного вами *дистрибутива* (например: apt -t stable upgrade).
> 6.2.6. Работа с отдельными *дистрибутивами*
И так далее.
При таком разнобое в используемой терминологии уже, пожалуй, всё равно, какое
слово будет использовано. :) Ну, пусть будет "выпуск".
> А "Dynamic MMap" часто встречается? Если нет, я бы перевёл буквально, а
> кому будет не понятно, посмотрят код (если вообще найдётся кто-то, кому
> это встретится...).
Встречается лишь один раз.
Буквально - это "динамическое отображение в память"? В принципе, можно
провести аналогию с динамическим массивом... Хорошо, пусть будет буквально.
> > msgid "The package lists or status file could not be parsed or opened."
> > msgstr "Списки пакетов или файл состояния не могут быть открыты или
> > прочитаны."
> >
> > Здесь, пожалуй, не стоит использовать "разобраны".
> >
> > В остальных случаях используется "разобрать".
>
> ОК. Хотя "открыть" и "распарсить" соотносятся друг с другом по-другому,
> не так как "открыть" и "прочитать". То есть, можно не открыть (и поэтому
> не распарсить), а можно открыть, но не распарсить. С другой стороны,
> прочитать, как кажется, иногда интуитивно предполагает что-то типа
> "открыть" (типа "открыть для чтения"). То есть, если что-то не открыто,
> то оно и не прочитано (в одном из смыслов!). Смысловая вариативность (о,
> как завернул) слова "прочитать" может натолкнуть на странную
> интерпретацию этого сообщения. Вроде как мы файл открыли, доступ к нему
> есть, но не прочитали, значит ли это, что доступа всё же нет?
Можно попытаться переформулировать:
"Не удалось открыть или разобрать содержимое списков пакетов или файла
состояния"
Но меня смущают два "или", которые в исходном варианте не так бросаются в
глаза.
> >> > msgid "Packaging system '%s' is not supported"
> >> > msgstr "Система пакетирования «%s» не поддерживается"
> >>
> >> Какие идеи, что тут и далее имеется в виду под "packaging system"? Может
> >> "система создания пакетов" будет лучше?
> >
> > См. комментарий в apt-pkg/pkgsystem.h. Это такой уровень абстракции,
> > позволяющий использовать разные системы пакетирования. Скажем, поддержка
> > dpkg не прибита гвоздями к APT, а является реализацией этой абстракции.>
> >
> > Затрудняюсь придумать перевод получше.
>
> "Система работы с пакетами"?
Может, "система управления пакетами"?
> >> > msgid "You must put some 'source' URIs in your sources.list"
> >> > msgstr ""
> >> > "Вы должны заполнить sources.list, поместив туда URI источников пакетов
> >> > с исходным кодом"
> >>
> >> Я бы сделал "Вам следует заполнить...".
> >
> > Может, тогда просто "Заполните..."?
>
> Да. Или "Необходимо заполнить".
Поразмыслив, могу сказать следующее: "вам следует" и "заполните" слишком
слабые, и больше подходят для предупреждения, чем для ошибки. "Необходимо
заполнить" уже лучше, но чем всё-таки вам не приглянулся изначальный вариант,
который ближе всего к оригиналу?
> "Как я сказал" уже предполагает примерно 50% (потенциальных, не
> фактических) пользователей. Всё же предлагаю никого не обижать и сделать
> гендерно-нейтральный вариант "говорю".
Ах, об этом факторе я вообще не подумал даже. Согласен, пусть будет "говорю".
> >> > msgid "Unable to correct missing packages."
> >> > msgstr "Невозможно исправить ситуацию с отсутствующими пакетами."
> >>
> >> "исправить отсутствующие пакеты"?
> >
> > Как можно исправить отсутствующие пакеты?
>
> Тут как раз и говорится, что это невозможно сделать. Не знаю, в какой
> ситуации возникает такое сообщение, но предполагаю, что пользователь
> отдаёт команду на исправление пакетов, а apt отвечает, что это сделать
> нельзя, так как пакетов нет.
Не совсем. Это сообщение выводится в случае использования опции --fix-missing
(см. apt-get(8)) и её неудаче, т.е. когда просто оставить отсутствующие пакеты
в неизменном виде без ломания других не удалось. Так что нужно либо оставить
текущий вариант перевода, либо переформулировать приблизительно так:
"Невозможно исправить отсутствие пакетов"
> >> > msgid "get configuration values via shell evaluation"
> >> > msgstr "получить значения настройки через вычисления оболочки"
> >>
> >> "вычисление" тут не нравится. Не знаю, как перевести.
> >
> > Да, мне тоже не понравилось, но вменяемого альтернативного перевода я ни
> > найти, ни придумать не смог.
>
> Может "выполнение сценария командной оболочки" или "выполнение кода
> оболочки". Ещё "через" можно заменить на "с помощью".
"Через выполнение кода оболочки" - вроде ничего так.
> >> > msgid "Erase downloaded archive files"
> >> > msgstr "удалить скачанные файлы архивов"
> >>
> >> Тут и ниже "файлы архивов", мне кажется, не очень. Надо что-то другое.
> >
> > Можно, конечно, просто "архивов", но я не вполне понимаю, почему "файлы
> > архивов" не очень подходит. Объясните?
>
> Не уверен, но для меня интуитивно слово "файлы" ничего не добавляет к
> "архивов". Вот, если "архивные файлы", тут, да.
В принципе, можно и убрать "файлы". Получится:
"удалить скачанные архивы"
Но в оригинале именно "файлы архивов", поэтому я бы оставил, как есть.
> Кроме того, возникает
> ощущение, что этих файлов где-то там много, хотя, по сути, видимо один?
Нет, как раз таки за редким исключением - много. Это же описание команды clean
программы apt-get.
> >> > msgid "%s was already not hold.\n"
> >> > msgstr "%s уже помечен как не зафиксированный.\n"
> >>
> >> А не слитно ли тут "не"?
> >
> > Не уверен, так как в данной фразе, на мой взгляд, присутствует скрытое
> > противопоставление. Есть термин "зафиксированный пакет", и в данном
> > предложении указывается на непринадлежность к заданному этим термином
> > множеству.
>
> Тогда можно "не" перенести, будет так: "уже не помечен как"
Поразмыслив, решил остановиться на слитном написании.
> > У меня есть сомнения насчёт:
> > "...для получения последних (возможно, _не выпущенных_) обновлений
> > пакета.\n"
>
> Мне кажется, тут слитно.
Мне тоже. Значит, если ни у кого не найдутся возражения, поменяю на слитное
написание.
> >> > msgid "Bad header line"
> >> > msgstr "Неверный заголовок"
> >>
> >> "строка заголовка"
> >
> > Разработчики почему-то используют нестандартную терминологию. Скажем, в
> > случае выше речь идёт о строке статуса (status line), а в данном - о
> > неправильном формате самого заголовка. Честно говоря, хотелось бы
> > использовать общеупотребляемую терминологию, а не переводить дословно
> > "изобретения" авторов APT.
> >
> > Таким образом, сообщение выше должно быть переведено как "HTTP-сервер
> > послал неверную строку статуса". В данном же сообщении, пожалуй, можно
> > и "Неверная строка заголовка" использовать - смыслу вроде не
> > противоречит.
> >
> > Что думаете?
>
> Честно сказать, затрудняюсь. Я бы сделал как в оригинале.
Разумно, конечно, просто боюсь, что эти сообщения ничего не дают понять о
причине ошибки. Впрочем, это вина разработчиков.
> >> > msgid "This HTTP server has broken range support"
> >> > msgstr "Этот HTTP-сервер не поддерживает скачивание фрагментов файлов"
> >>
> >> Тут fuzzy.
> >
> > Да, так как я не уверен, что делать с этим сообщением.
> >
> > "Сервер не поддерживает" - это когда сервер, например, посылает "Accept-
> > Ranges: none", т.е. адекватным образом сообщает об отсутствии (или не
> > сообщает о наличии) поддержки запросов диапазонов. Такая поддержка
> > опциональна, так что это не является ошибкой.
> >
> > В данном же сообщении идёт речь о сломанной поддержке, когда сервер
> > посылает неадекватные данные о диапазоне.
> >
> > Да, можно было бы перевести это сообщение так:
> > "У этого HTTP-сервера сломана поддержка скачивания фрагментов файлов"
> > - но мне такой вариант не нравится. Лучшее, что я пока смог придумать:
> > "Поддержка байтовых диапазонов в данном HTTP-сервере реализована
> > некорректно"
> >
> > (Диапазоны в теории могут быть не байтовыми, но во-первых, APT использует
> > именно их, а во-вторых, до сих пор ни один другой тип не был
> > зарегистрирован:
> > http://www.iana.org/assignments/http-parameters/http-parameters.xhtml#ran
> > ge-units)
> >
> > Что скажете?
>
> Может так:
>
> "Этот HTTP-сервер на запрос байтовых диапазонов ответил некорректно"
Оно, конечно, правильно, однако в исходном сообщении ничего не говорится про
запрос. Но в целом варианты приблизительно эквивалентны.
Reply to: