Skip site navigation (1) Skip section navigation (2)

Re: Re: Закончен перевод PostgreSQL 9.1

From: "Andrey N(dot) Oktyabrski" <ano(at)bestmx(dot)ru>
To: pgsql-ru-general(at)postgresql(dot)org
Subject: Re: Re: Закончен перевод PostgreSQL 9.1
Date: 2012-02-21 18:58:30
Message-ID: 4F43E956.8010301@bestmx.ru (view raw or flat)
Thread:
Lists: pgsql-ru-general
On 21.02.12 16:57, Alexander LAW wrote:
> Давайте обсудим следующие предложения. Я не знаю, как удобнее - в
> рассылке или в wiki, поэтому начну так.
>
>> chunk - кусок, фрагмент, часть
> против "порция" (порция была здесь
> http://wiki.postgresqlrussia.org/index.php/%D0%A2%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%D1%8B_PostgreSQL)
> в тексте кроме упомянутого больше вхождений нет, на мой взгляд ни один
> из трёх вариантов не делает фразу "Максимальный размер порции TOAST" лучше
+1 за фрагмент

>> fork - разветвление, ответвление
> возможны два контекста:
> 1) to fork a process
> я так понимаю, что это просто запустить дочерний процесс - чтобы
> разойтись со словами launch/start я предлагаю использовать фразу
> "породить процесс"
Хороший перевод.

> 2) fork of a table
> Из документации:
> |pg_relation_size| accepts the OID or name of a table, index or toast
> table, and returns the on-disk size in bytes. Specifying 'main' or
> leaving out the second argument returns the size of the main data fork
> of the relation. Specifying 'fsm' returns the size of the Free Space Map
> (see Section 55.3
> <http://www.postgresql.org/docs/9.1/static/storage-fsm.html>) associated
> with the relation. Specifying 'vm' returns the size of the Visibility
> Map (see Section 55.4
> <http://www.postgresql.org/docs/9.1/static/storage-vm.html>) associated
> with the relation.
>
> я думаю, что здесь перевод "размер ответвления основных данных
> отношения" или "ответвления свободного пространства, связанного с
> отношением" или "ответвления карты видимости" - будет не очень удачным.
"карта незанятых фрагментов" и "карта видимости" может быть?

>> log - журнал, лог
> также два контекста:
> 1) журнал транзакций
> так и есть журнал
> 2) текстовый файл, содержащий сообщения сервера
> я решил использовать слово "протокол", которое также используется в
> данном контексте, и позволяет избежать пересечений с "журналом транзакций".
"Протокол" хорошее слово. Но если сказать "лог", всем будет понятнее :-)

>> major - старший
>> minor - младший
> major version использовалось один раз, в данном контексте мне
> показалось, что "базовая версия" будет лучше.
> "на компьютере установлен Python базовой версии 2.7" против "на
> компьютере установлен Python старшей версии 2.7"
> но если это критично для понимания, соглашусь
И то, и то плохо. Подумаю, может и рожУ что-то...

>> not valid index - неправильный, недопустимый индекс
> я не думаю, что признак indisvalid обозначает именно неправильный или
> недопустимый индекс. Скорее это индекс, временно находящийся в нерабочем
> состоянии.
> В комментариях catalog/index.c написано следующее
>   * After completing validate_index(), we wait until all transactions that
>   * were alive at the time of the reference snapshot are gone; this is
>   * necessary to be sure there are none left with a transaction snapshot
>   * older than the reference (and hence possibly able to see tuples we did
>   * not index).    Then we mark the index "indisvalid" and commit.
> Subsequent
>   * transactions will be able to use it for queries.
>
> Может быть кроме нерабочий ещё подойдёт "негодный".
"Неактуальный" лучше.

>> option - опция (а параметр - это parameter)
> Мне кажется, что при запуске программы ей передаются параметры.
> Параметры её выполнения. А с опциями это не получается. Хотя может быть
> это дело вкуса.
+1 за опцию. Может быть ещё "настройка", но это по-моему хуже.

>> row - строка таблицы (термин кортеж не совсем правилен, потому что
>> кортеж (на сколько я понимаю) это информация о сущности, а row -
>> строка ЛЮБОЙ таблицы, полученной в том числе как результат запроса).
>> Кортеж - это скорее tupple, хотя (на мой взгляд) разница между row и
>> tupple довольно условна.
> tuple тоже переводится как кортеж, но есть контекст, в котором надо
> отделить "строки таблицы" от "строк текстовых", при этом усложнять
> предложение дополнительными словами нежелательно
Строки таблиц издревле называют "записями", а столбцы - "полями". 
По-моему, хорошая традиция.

>> shared - разделяемый. Общим может быть конфиг /etc/postgresql.conf, но
>> он не является shared
> хорошо, в подобном контексте я переделаю на "разделяемый"
+1 за разделяемый.

>> symbolic link - я предпочитаю "символьная", потому что ссылка из
>> символов, но она ничего не символизирует, поэтому не является
>> "символической"
> хорошо, соглашусь, хотя можно трактовать по-разному, например, что в
> символической ссылке создаётся "символ" файла
Где-то мне ещё встречался термин "мягкая ссылка". Но "символьная" 
наверное понятнее будет.

>> token - токен. А не "маркер". В слове prelink, если мы говорим о
>> слогах, pre может считаться токеном, а маркер здесь не катит.
> здесь два контекста
> 1) контекст безопасности
> в Windows (к ней это относится) принято, что token - это маркер, маркер
> доступа
Здесь "билет", "ключ", "пропуск" - что-то такое.

> 2) разбор текста при полнотекстовом поиске
> здесь мы можем сказать и токен, но не хочется транслитерации, если есть
> подходящее слово - фрагмент, фрагмент фразы, фрагмент текста
Токен - это не фрагмент. Это скорее атом - неделимая единица. Может быть 
"слово" лучше отражает суть термина?

>> truncate table - урезать таблицу. truncate не означает полное
>> обнуление таблицы поэтому неправильно говорить об "опустошении"
> "урежьте таблицу" на мой взгляд не звучит, и в документации написано:
> TRUNCATE -- empty a table or set of tables
> а "сделать пустой" - по-моему вполне можно заменить на "опустошить"
Очистить? Вроде так более по русски.

In response to

Responses

pgsql-ru-general by date

Next:From: Andrey N. OktyabrskiDate: 2012-02-21 19:01:04
Subject: Re: Re: Закончен перевод PostgreSQL 9.1
Previous:From: Виктор ВислобоковDate: 2012-02-21 18:44:15
Subject: Re: [pgsql-ru-general] Re: Закончен пере

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group