1. пишем код, почти как обычно;
2. запускаем приложение, сканирующее исходники на предмет текста, который нужно перевести;
3. генерим РО файлы;
4. переводим их в любом удобном редакторе;
5. компилим РО файлы в МО файлы;
6. на выбор либо внедряем перевод прямо в ЕХЕ либо кладём МО файлы рядом;
7. наслаждаемся результатом — язык приложения можно менять даже без перезапуска.

• минимум изменений в коде приложения;
• никаких DLL и сторонних компонентов, всё OpenSource;
• РО файлы — достаточно распространенный инструмент перевода, что значит перевод можно даже отдать на аутсорс, и переводчик знает что с этим делать;
• перевод всего — формы, фреймы, месседжбоксы, и всё что угодно;
• корректный перевод слов в множественном числе в любом языке;
• полная поддержка Unicode.

Или как можно проще об основных принципах ООП в Lazarus и FreePascal

Часть I

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

Во всех книгах, посвященных паскалю, delphi и lazarus (я нашел аж целых две о последнем), очень схожая часть, посвященная ООП. По этим книгам можно много узнать о том, насколько круче ООП устаревшего структурного подхода, но так и не получить достаточных навыков применения этого на практике. Конечно, любой программист, использующий визуальные IDE, уже по умолчанию использует ООП, так как все компоненты и структурные элементы визуального приложения представляют собой объекты, однако свои собственные структуры и абстракции перенести в парадигму ООП бывает очень сложно. Чтобы понять всю прелесть и оценить открывающиеся перспективы, я решил сделать небольшое приложение, которое в конечном итоге превратилось в простенький screensaver. Заодно вспомнил о существовании тригонометрии.

Приложение будет рисовать на экране в случайных местах пятьдесят полярных роз с разными характеристиками: размер, цвет, количество лепестков. Потом их же затирать и рисовать новые, и т.д. Используя принципы структурного программирования, можно, конечно, сделать обычный многомерный массив объемом на 50 и в нем сохранять все уникальные характеристики. Однако стоит вспомнить, что паскаль подразумевает строгую типизацию данных, а, следовательно, массив не может состоять их элементов с разными типами. Можно сделать массив из записей (record), но чего уж мелочиться, от записи до класса — один шаг. Вот его мы и сделаем.

Предисловие.

В своей работе (юридической) я готов автоматизировать всё, что только поддаётся этому. Но пока прокачанные нейросетями роботы из утопии Германа Грефа не появились и не отняли всю работу у рядовых юристов, рутина надолго останется нашим главным спутником. Автоматизация этой рутины — то, чем я периодически занимаюсь на протяжении последних лет, будь то многочисленные таблицы в excel с кучей формул, позволяющих быстро распечатать сотню однотипных документов-рассылок в word'е, ну или автоматически генерируемые отчеты. Но есть и такие вещи, которые простыми формулами и подстановками не сделаешь. Здесь на помощь приходит программирование, которым я увлекаюсь с детства, и так уж вышло, что началось это с delphi. Сейчас мне проще, чем в C# или python, осваивать которые начал недавно, сделать быстро какой-то проект в среде Lazarus, используя freepascal. И да, я на полном серьёзе считаю, что возможностей этой среды более, чем достаточно. Поэтому автоматизировать ЕГРЮЛ, как вы догадались, предстоит с помощью паскаля.

От переводчика

Добрый, предновогодний день всем! В этой статье я бы хотел рассказать, как мне пришлось вернуться в legacy-проект на паскале, причем буквально перед тем, как навсегда распрощаться и с ним, и с лазарусом, и с отсутствием темной темы из коробки.

В прошлый раз я объяснял, что не являюсь программистом по роду профессиональной деятельности, но использую любимое хобби для автоматизации всего, что попадается под руку в работе юриста. Я уверен, что 90% всей юридической волокиты может быть успешно автоматизировано: ведение разнообразных баз и карточек, составление документов по шаблонам, контроль сроков выполнения задач, использование любых вспомогательных сервисов, уже имеющих свои api, для прикручивания автоматизации на конкретном рабочем месте и т.д. К этому нужно стремиться, чтобы по заветам Айзека Азимова высвободить время юриста для реализации основной задачи - размышлять над условиями договора и разводить демагогию в суде.

Вы когда-нибудь пробовали разобраться в том, что же происходит внутри ansible-vault? А ещё лучше - не только разобраться, но и что-то сделать на основе полученных знаний? Так вот, статья именно об этом: разбираем исходники ansible, а потом пишем свой расшифровщик для ansible-vault.

Язык для написания расшифровщика был выбран по принципу "я - автор статьи, выбираю что хочу язык под задачу, исходя из технических требований". Результат компилируется за 0.6 секунд в исполняемый файл размером 800Кб, который не требует внешних библиотек.

Заинтригованы? Добро пожаловать под кат!