Обновил перевод GUI до bzr5536.
Добавлен превод описания "горячих" кнопок.
На lp kicad-doc bzr701.
Замечания-пожелания-предложения приветствуются.
Тарболл со свежей версией на фтп - перевод есть внутри, CmakeLists.txt поправлен на сборку сразу с переводом
(можно kicad-doc отдельно не собирать).

Спасибо, проверил на rev. 5538 (OS X) появилась руссификация изменённого в pcbnew меню Настройки.

Так, а можно теперь для чайников: вот я собираю минимальный вариант из официального репа. Делаю bzr checkout lp:kicad, cmake и т.д. В программе есть меню смены языка, но оно ни на что не влияет. Что мне надо сделать, чтобы добавить ваш перевод? Желательно по шагам.

А то я увидел в первом сообщении знакомые буквы lp и kicad-doc, сделал bzr checkout lp:kicad-doc, получил ошибку "bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/+branch/kicad-doc": no supported schemes" и понял, что делаю что-то не то.

Когда Вы собираете сам kicad это одно, а русификация просто должна лечь в нужное место после установки или во время установки, смотря какой вариант сборки.
В любом случае, чтобы увидеть русифицированный кикад, русификатор должен лежать в нужном месте, где кикад его ищет/берёт при работе.

P.S. в win это в папке программы в share/...
в OSX это в ~/Library/Application Support/kicad/share/internat/ru

Понятно. Значит пока я все делаю правильно. Речь в первом сообщении шла о CmakeLists.txt, значит эту документацию можно как-то собрать из исходников? Где их взять и есть ли какие-то особенности при сборке?

Сами "исходники" находятся в ветке lp:~kicad-developers/kicad/doc
Редактируются на сколько помню po-редактором, в итоге получаем .mo-файл, который при работе и использует kicad,
однако и исходник (*.po) и готовый к использованию бинарник (*.mo) присутствуют в ветке.

Таким образом необходимо просто правильно разместить в структуру каталогов программы kicad этот файл.

P.S. процесс локализации описан в doc/GUI_Translation_HOWTO.pdf

Спасибо, получилось.

Если кто-то захочет повторить:
1) в какой-то папке делаем bzr co lp:~kicad-developers/kicad/doc
2) из получившейся папки копируем папку internat в ${install_prefix}/share
3) содержимое папки doc копируем в ${install_prefix}/share/doc/kicad

В kicad-doc есть свой CmakeLists.txt.
Я же для себя сделал изменения в kicad-dev/CmakeLists.txt, добавив в сборку диру internat, но на lp:kicad не коммитил.
Эти изменения позволили избежать лишних телодвижений при сборке тестовой ветки (не надо собирать kicad-doc и/или перемещать руками перевод в /usr/share/kicad...),
т.е. при сборке в пакет сразу добавляется перевод. Соответствующий spec для сборки rpm есть на фтп.
По шагам: обновил исходники (bzr pull lp:kicad), poedit для исправления/редактирования перевода, формирование tar-архива с исходниками и переводом, корректировка
spec (при необходимости), сборка пакета, обновляем пакет в системе, работаем/проверяем/тестируем.
Протестированный перевод из kicad-dev/intrenat/pu/kicad.{po,mo} копирую в kicad-doc-lp, коммичу (если есть что) на lp:kicad-doc.

На сайте http://docs.kicad-pcb.org появилась обновленная документация на английском, итальянском и польском языках с учетом
последних изменений в Kicade. Русская документация не обновлялась с 2012 г. Хотелось узнать у автора русского перевода
будет ли обновление.

Недавно попробовал переводить документацию на новый формат. Как оказалось, нет ничего сложного, задача каждому под силу, вот только отнимает много времени.
Уже перевел "Вводный курс для пользователя KiCad" и "CvPcb". Использовал имеющуюся документацию как ориентир, но некоторое содержимое устарело, много нового добавлено, особенно в CvPcb.
Если есть желающие помочь, можно разделить документацию на части и сообща обновить ее, было бы не плохо поработать командой

Но пишу это сообщение с другой целью. В процессе перевода я заметил, что нет единого обозначения для некоторых элементов программы, так сказать отсутствует единая терминология. В результате, одни и те же элементы обозначены по-разному и могут вводить новичков в заблуждение. Например, в CvPcb и в Pcbnew есть пункт в меню "Настройки", который делает одно и тоже - вызывает диалоговое окно для редактирования таблиц библиотек посадочных мест, но при этом называется по разному:
в CvPcb - "Библиотеки посад.мест";
в Pcbnew - "Менеджер библиотек посад.мест";
при чем само диалоговое окно называется "Таблицы библиотек печатной платы".
Я считаю, элементы меню и само диалоговое окно должны именоваться одинаково - "Таблицы библиотек посадочных мест".
Думаю, не стоит использовать сокращения, типа "посад.место", "конт.пл.". Места экономится не так уж и много, а воспринимается сложнее.
Далее, меню "Просмотр" (View) в большенстве программ переводится как "Вид".
В меню "Справка" пункт "Приступая к работе в KiCad" открывает "Вводный курс для пользователя KiCad", тоже нужно назвать одинаково, ну и так далее.

В смой документации встречал фразы "... кликнуть мышкой на иконку ... в верхней инструментальной панели ...". Как по мне, лучше использовать более техничные определения (как в учебниках по информатике), например, "... щелчек левой кнопкой мыши на кнопке ... на верхней панели инструментов ..." или, как вариант, "... нажать кнопку ... на верхней панели инструментов ...".

В общем, предлагаю здесь, в этой теме, вместе, создать некое подобие справочника переводчика для KiCad и собрать переводы специфических терминов программы. Таким образом, работая командно, мы сможем получить документацию с единым стилем перевода, что будет смотреться более понятно и качественно.

Начать можно с самых основных:

footprint - посадочное место
component - компонент схемы (условное графическое обозначение УГО ?)
footprint library table - таблица библиотек посадочных мест
...
toolbar - панель инструментов
statusbar - строка состояния
click on icon - нажать кнопку
...
ну и так далее в таком же духе.

Хотелось бы узнать ваше мнение по этому поводу.

А может сделать отдельную тему "Справочник для переводчика KiCAD"?
И в топике этот справочник обновлять? Ну а дальше - предложения и обсуждения..

зы (первое обсуждение)
имхо, "component" = "компонент", т.к. термин всегда(?) употребляется в контексте eeschema и определяет не только УГО, но и другие параметры.

Хорошая идея. Если соберется побольше заинтересованных, так и сделаем.


Тут есть над чем подумать. Под "компонентом" можно подразумевать некую деталь, которая имеет графический символ в схеме, посадочное место на плате и 3D модель реального представления. Я считаю, лучше разделить эти составляющие между соответствующими программами:
Eeschema - символ, условное графическое обозначение (больше склоняюсь ко второму варианту) компонента;
Pcbnew - посадочное место компонента;
3D-view - трехмерное представление, 3D-модель (по мне, первый вариант) компонента;
CvPcb - связывает/назначает/сопоставляет(?) графическое обозначение и посадочное место.

Когда-то, помню, и разработчики KiCad'a подымали подобный вопрос. Решали что лучше использовать в Eeschema "symbol" или "component", а в Pcbnew - "module" или "footprint". В конце решили в Pcbnew использовать "footprint", а вот про Eeschema не помню. Но Pcbnew они сейчас усилено пилят, а Eeschema пока не трогают, может вскоре тоже займутся.

Позволю себе поспорить
У них: "A component is a schematic element which contains a graphical representation, electrical connections, and fields defining the component."
Т.е. это больше чем УГО: он содержит ещё и метаданные электронного компонента. В т.ч. полное наименование и корпус.

зы Наши коллеги-конкуренты из Эремекса тоже остановились на паре "Компонент" - "Посадочное место"

alex9, согласен. Кстати, можно ориентироваться на их документацю. Оформленно годно. Хотя, есть некоторые сомнительные места. Например, "нетлист" (используется транскрипция от "netlist") можно было перевести как "список соединений" или "список цепей".

Барановский Константин, создавайте (как главный переводчик) тему "Справочник для переводчика KiCAD": количество заинтересованных увеличилось в два раза.
Попробую перевести GerbView (мне надолго хватит

Ну тему мы всегда успеем создать, дело не хитрое. Хотелось бы увидеть коментарий Андрея Федорушкова (faa). Когда согласуем возможность и варианты обновления перевода интерфейса программы - можно двигаться дальше.

Я временно только читатель .
По работе загрузили, гост-сборку обновляю в связи с производственной
необходимостью - очередной проект развесистый, ну и заодно тестирую новшества (особенно скругления падов радуют ).

UPD
По существу: Есть ГОСТ Р 53386-2009 - там привеены соответствия буржуйским терминам и определениям.
Но некоторые уж очень длинными получаются - их в GUI тяжело вставлять - все расползаться начинает.
Да и есть далеко не все.
Либо сокращать приходится, либо искать какой-то синоним.
Я так и не определился, как лучше - верхняя-нижняя или передняя-задняя сторона (top-bottom or front-back)
А в других ГОСТ, относящимся к печатным платам (напрмер, ГОСТ Р 53429-2009), есть сокращения - может на них и ориентироваться?
На этом форуме было уже обсуждение (ЕМНИП) терминологии, скращений и пр. и как их применять. Даже к какому-то консенсусу пришли.
Его я и старался придерживаться при переводе гуя.

Извините, что вмешиваюсь, но в данном случае даже вопросов не возникает. Конечно верх-низ. Мне непонятно стремления соответствовать ГОСТ в вопросе терминологии, как, в принципе, и стремлению перевода интерфейсов, специализированных профессиональных программ или стремящихся подражать им. Освоить два-три десятка терминов на ангельском -- должно быть доступно интеллекту человека, занявшегося электроникой. Документация -- другой дело, но интерфейс...

Интеллекту доступно но я за ГОСТ.

"Gerber has three drawing primitives: flashes, lines and arcs"
Помогите найти вменяемый перевод для этих самых "flashes".

alex9, исходя из контекста:
flashes - отверстия
flashed items - элементы с отверстиями.
Но не уверен в корректности этого перевода.
P.S. Не нашел указанной фразы в исходном файле документации.

Фраза - общая про gerber. В доке - "Flashed items are converted to vias"
По сути и технологии, "flash" - это экспозиция выбранной апертуры фотопостроителя в заданной позиции. Но как сказать это короче?

Надо не короче, надо понятней читателю. Это же документация
Точки, линии, дуги. Форма точек определяется заданной апертурой.
А в контексте - flash тут как " вспышка" - апертуру выбрали, включили лампу, экспонировали, выключили - получили точечный элемент фотошаблона.



ГОСТ - это закон.
И как говорит знакомый представитель ВП: "Часть ГОСТов написана кровью".

"Flashed items" перевёл как "Элементы, заданные командой Gerber "засветка".
Попутно нашёл хорошее описание формата Gerber
Было бы здорово его усечённый вариант включить в комплект документации (хотя бы kicad-gost). Нажмите для просмотра прикрепленного файла

2 Барановский Константин
Вот, перевёл. Принимайте. Нажмите для просмотра прикрепленного файла

зы. Займусь idf_exporter

alex, спасибо большое за помощь и старания, но у нас, похоже, возникла проблема.
В результате перевода должны появиться:
1) файл po/addendum.ru с информацией об авторе (авторах) перевода;
2) файл перевода po/ru.po;
3) папка с руссифицированными скриншотами images/ru/*.
Сам файл gerbview.adoc переводить не нужно. Подробные иснтрукции о процессе перевода доступны здесь: https://github.com/KiCad/kicad-doc/blob/mas...structions.adoc

В общем случае процесс перевода должен быть следующим:
- зарегистрироваться на github.com;
- создать форк (кнопка Fork) репозитория https://github.com/KiCad/kicad-doc;
- клонировать (загрузить) ветку к себе на комп.;
- проследовать инструкциям https://github.com/KiCad/kicad-doc/blob/mas...structions.adoc;
- перевести ru.po, скриншоты;
- проверить перевод;
- сохранить изменения в ветке (commit);
- отправить изменения на github.com (push);
- на странице своего форка создать Pull request;
- дождаться внесения изменений в основную ветку;
- готово!

Можно, конечно, не регистрироваться на github, а просто скачать zip архив со всеми файлами, выполнить перевод и отправить мне po/addendum.ru, po/ru.po, images/ru/*, а я уже оформлю все и отправлю. Но так не честно, страна должна знать своих героев.

Как всё сложно
Попробую..

Возникнут вопросы, даже пустяковые, не важно - задавайте. Вместе разберемся. Самое сложное подготвить все. А потом, как по накатаной...

2 Барановский Константин
Вроде бы получилось. Нажмите для просмотра прикрепленного файла

Готово. Перевод уже в основном репозитории: https://github.com/KiCad/kicad-doc/commits/master

Такой вопрос возник. Буква "ё" должна отображаться как положено, с точками вверху, или упрощенно "е"?

Посмотрел, вроде бы правильно отображается. С точками.

alex9, я не это имел в виду.
Согласно правилам русского правописания, употребление буквы ё в большинстве случаев факультативно (т. е. необязательно). Вот я и спрашиваю, как нужно писать с "ё" или "е"? При переводе я использовал "е", но у Вас увидел "ё" и задался вопросом.

Поправлю Вас: "Согласно правилам русского бюрократически-формального правописания, употребление буквы ё в большинстве случаев факультативно (т. е. необязательно)"
Это правило родилось у ленивых секретарш и прочих функционеров-операторов, которые не смогли запомнить расположение буквы ё на клавиатуре, а искать - не по статусу. Чем осложнили жизнь многим людям!
Лонг Лив Буква Ё

Понял, исправлюсь.

- это я не про Вас.

Перед продолжением перевода документации решил просмотреть перевод интерфейса программы. Тут, на счет сокращений, я погорячился - без них никак.
В приложенном архиве три файла:
1) kicad-i18n.ru.patch - содержит изменения по отношению к последней версии перевода с github.com/KiCad/kicad-i18n (commit f422545); этот файл получен командой Удобно просматривать в текстовом редакторе с подсветкой синтаксиса;
2) kicad.po - измененный файл перевода интерфейса программы;
3) kicad.mo - скомпилированный файл перевода - можно подложить в KiCad и просмотреть изменения в самой программе.

Основные изменения:
- исправлены пункты меню разных мастеров и менеджеров, чтобы не возникало путаницы;
- разные палочки-стрелочки заменены словами (например, "Повернуть Х <-" заменено на "Повернуть Х по ч.ст." и т.д.);
- буква "ё";
- мелкие правки найденных опечаток и, на мой взгляд, не верных формулировок ("Current project directory" - "Текущая директория проекта" заменена на "Директория текущего проекта" и т.п.).

Прошу высказать ваши предложения, замечания, дополнения. Готов обсудить. Надеюсь faa найдет время и поможет нам определиться с окончательным вариантом перевода интерфейса программы. Когда это будет сделано можно смело переводить оставшуюся часть документации (так как там много отсылок к интерфейсу программы, и не хотелось бы по два раза проделывать одну и ту же работу).

Барановский Константин
Я бы только слово "директория" не употреблял. Лучше "каталог" или, как сейчас стали внедрять, "папка".

От части сокращений можно избавиться:
вместо "Повернуть Х по ч.ст." - "Повернуть X вправо". Даже короче получается.
Кстати, "Повернуть Х <-" - больше похоже на "Повернуть X против часовой стрелки", то есть влево.

Вот "папок" не надо - не все пользуются "проводником" виндовса. "Каталог" - да, пожалуй. ГОСТ есть какой-нибудь на эту тему? Должен быть...

Поддерживаю, я бы постарался избегать сокращений. Несколько предложений из того, что заметил при беглом просмотре:

Невозможно найти файл помощи.

Неофициальные?

Тут есть лишний пробел и это не единственное такое место.

Просто "дублирован".

Для обозначения ориентации страницы используются "ландшафт/портрет". Может быть использавать прилагательные для этих терминов?

Может лучше "справочной информации"?
вертикальный/горизонтальный.

Можно прислушаться к википедии и остановиться на "каталог"е.

Не уверен, что это верно. Имеется в виду поворот вокруг оси, а вправо-влево можно сдвигать, но не вращать. По поводу направления, я руководствовался следующим: открыл просмотрщик 3D, по-умолчанию ось Z направлена на меня, выполняю "Повернуть Z <-" - плата вращается по часовой стрелке. Вот я и принял, что "<-" - "по часовой стрелке".
Если не прав, поправьте.

Согласен, так лучше. Но смысл фразы не меняется. Я старался вносить наиболее критичные правки.

Исправлю.

Поищу и исправлю. Но в некоторых фразах в исходном тексте тоже используются отступы из двух пробелов, как поступать с ними?

Заменю.

В меню программы используется термин "Руководство ...". Может, "Невозможно найти файл руководства пользователя ..."?

Как по мне, лучше "портретный/ландшафтный".

Да, так будет хорошо.
Да, что-то меня переклинило. В ГОСТ используется термин "расположение основной надписи вдоль длинной/короткой стороны листа", что нам явно не подходит.

Я так понял, чтото перевод от production ветки?
Попробую его наложить на ГОСТ-ветку.
С переводом production теперь есть некоторые сложность в связи с перездом на github,
через pull request надо делать (а в members еще не включили).

Сразу замечания по фразеологии: ИМХО не стоит использовать "невозможно" и т.п. обороты, лучше звучит "не удалось".
Да и пользователь меньше пугается



Портрет/пейзаж? Часто так переводят. Можно еще вертикально/горизонтально.
А4 только портрет - штамп вдоль короткой стороны по ГОСТ.

UPD: Пока использую ГОСТ-вестку, поддерживая ее актуальность. Но опять основную "улучшили-отрефакторили" где-то в bzr664x - на больших масштабах тормозит жутко.
Макросы "выпилили" полностью, а с большими проектами без них трудно
Да и бодаться с супостатами надоело.

На мой взгляд:


"Сбросить всё по умолчанию" или "Всё по умолчанию"

"мм" проще воспринимается, чем "миллиметры".

+"включённые KiCad. Подробности смотрите в разделе \"Таблица "

"По левому краю"
"По центру"
"По правому краю"

@@ -4998,11 +4999,11 @@ msgstr "Гориз. выравнивание"

"По верхнему краю"
"По нижнему краю"

"Он был ... Пожалуйста, исправьте."

Отлично! Накопилось довольно много предложений и замечаний, решил подвести небольшой итог:

- "каталог" вместо "директории";
- "руководство пользователя" вместо "файла помощи";
- "не официальные" - "неофициальные";
- "задублирован" - "дублирован";
- удалил лишние пробелы;
- ориентация листа: "ландшафт" - "горизонтально", "портрет" - "вертикально";
- заменено "невозможно" на "не удалось" в тех местах, где это уместно;
- "Сбросить всё на по умолчанию" - "Всё по умолчанию" (исходя из содержимого контекстного меню - наиболее удачный вариант);
- "миллиметры" - "мм";
- "Для большей информации смотрите раздел" - "Подробности смотрите в разделе";
- "Выровнять слева" - "По левому краю";
- "Выровнять по центру" - "По центру";
- "Выровнять справа" - "По правому краю";
- "Выровнять снизу" - "По верхнему краю";
- "Выровнять сверху" - "По нижнему краю";
- "Он был ... Пожалуйста поправьте это." - "Он был ... Пожалуйста, исправьте.".

Результат в приложенном архиве.

Барановский Константин

В Foxit Reader'е, например, написано именно "Повернуть влево" и "Повернуть вправо" (По-английски - "Rotate Left", "Rotate Right").


Надо сделать, как фактически работает.

break, пусть нас рассудят другие пользователи. Как для вас понятнее, удобнее?

Фактически, есть "Поворот в одну сторону" и "Поворот в другую сторону", т.к. при просмотре нет жёсткой фиксации направления осей. Направление поворота сменится, если Вы посмотрите на модуль не сверху, а снизу. Поэтому, нет необходимости привязываться к часовой стрелке. И французский вариант имеет право быть.

А можно подойти к вопросу поворотов строже и рассмотреть пиктограммы на кнопках.
Если смотреть вдоль положительного направления оси, то кнопка с подсказкой "<-" соответствует положительному направлению поворота (против часовой стрелки). Т.е. "Повернуть X +".

Направление вращения я определил не верно. Почитал немного информации о вращении тел в пространстве и сделал вывод, наблюдатель должен находится в центре, т.е. в начале системы координат. Тогда ось должна быть направлена от меня...
Но так как оси, чаще всего, находятся в произвольном направлении, сложно сориентироваться в какую сторону нужно повернуть тело, чтобы оно приняло нужное положение. Для меня, например, проще просто поклацать кнопки и таким образом определить нужное мне направление вращения, чем мысленно поворачивать тело, так чтобы нужная ось была направлена от меня и затем определить нужное направление. Я клоню к тому, что, может, оставить как было, стрелками - "<-" туда, "->" сюда?