Вопрос или проблема
Я хочу получить красиво локализованные названия пакетов APT, такие как “LibreOffice Writer” (а не libreoffice-writer). Я пишу скрипт, которому нужна эта информация.
Я могу получить локализованное описание пакета с помощью команды apt show libreoffice-writer. Однако она не показывает локализованный заголовок пакета. Я могу найти только libreoffice-writer как имя, я не могу найти LibreOffice Writer в каком-либо из полей, которые отображает apt show.
Я знаю, что это локализованное имя где-то хранится. Менеджер обновлений Ubuntu получает это имя откуда-то, как вы можете увидеть на этом скриншоте:
Я нашел код в Менеджере обновлений, который получает название пакета. Оказывается, он пытается найти соответствующий .desktop файл для пакета, чтобы найти локализованный заголовок пакета.
Вот как я доказал это самому себе. Я отредактировал libreoffice-writer.desktop файл, чтобы изменить его имя, вот так:
sudo desktop-file-edit --set-name 'LibreOffice Writer Foobar' /usr/share/applications/libreoffice-writer.desktop
Теперь, когда я открываю менеджер обновлений, я вижу, что используемое имя было изменено на то, которое я выбрал (“LibreOffice Writer Foobar”):
Вы можете найти этот код в /usr/lib/python3/dist-packages/UpdateManager/Core/UpdateList.py.
Возможно, вам стоит взглянуть на пакет app-install-data, но это все, что я могу сказать, так как я наткнулся на это, занимаясь уборкой. Но вы также можете попробовать whatis. У меня похожий случай использования, для которого я придумал следующее:
$ whatis true | head -n1 | tr '[[:blank:]]' ' '
true (1) - do nothing, successfully
whatis в основном просто ищет страницы руководства и перечисляет их строки ‘NAME’. И поскольку политика Debian требует страницы руководства практически для всего, это должно работать для всех установленных пакетов приложений. По крайней мере, я сомневаюсь, что разработчики Ubuntu, которая основана на Debian, пойдут на то, чтобы удалить страницы руководства. Плюс, вам не нужно разбирать .desktop файлы. Также пакеты, предоставляющие .desktop файлы, являются лишь подмножеством пакетов, содержащих страницы руководства.
РЕДАКТИРОВАНО:
Если вы выберете предложение whatis, возможно, вам стоит установить локализованные страницы руководства, например, sudo apt install manpages-fr, что должно также обеспечить автоматические локализованные имена. Но локализованные страницы руководства также являются лишь подмножеством всех доступных страниц руководства. Однако, я готов поспорить, их все же больше, чем .desktop файлов.
.
Ответ или решение
Для решения проблемы получения локализованных названий пакетов APT, таких как "LibreOffice Writer", необходимо обратиться к пониманию основного механизма представления программ в интерфейсах и в самой системе. Эта задача требует знаний о том, как операционная система Ubuntu (и её основные компоненты) структурируют и отображают информацию о программах для пользователей.
Теория
Когда вы сталкиваетесь с задачей получения "красивого" локализованного имени пакета, вы должны понимать, что в большинстве случаев название пакета (например, libreoffice-writer) используется системой для идентификации на уровне APT и других системных утилит. Однако пользовательские интерфейсы, такие как диспетчер обновлений, могут отображать программы с более удобоваримыми именами. Эти имена берутся из других источников информации, которые сближают именование программ с привычным для пользователя видом.
На практике источником этих имен часто являются .desktop файлы. Это специальные файлы, которые предоставляют информацию о приложении, такую как имя, комментарии, иконку и пути к исполняемым файлам. .desktop файлы располагаются преимущественно в каталоге /usr/share/applications/. Эти файлы могут содержать информацию на нескольких языках, если локализация предусмотрена разработчиком.
Еще один возможный источник информации — это man-страницы, однако они менее детализированы в части предоставления красивых имен приложений. Впрочем, для системных утилит whatis в большинстве случаев достаточно.
Пример
Допустим, вы разрабатываете скрипт, который должен отобразить список установленных пакетов с локализованными именами. Вам необходимо понимать, откуда брать такие имена и как с ними работать. В случае пакета libreoffice-writer, чтобы получить "LibreOffice Writer", вам, скорее всего, придется отфильтровать соответствующий .desktop файл.
Пример команды для редактирования .desktop файла с помощью desktop-file-edit может выглядеть следующим образом:
sudo desktop-file-edit --set-name 'LibreOffice Writer Foobar' /usr/share/applications/libreoffice-writer.desktopПосле внесения изменений вы сможете наблюдать, как обновленное имя отобразится в интерфейсах, использующих .desktop файлы.
Применение
Чтобы имплементировать решение в вашем скрипте, вам придется написать логику, которая:
- Сканирует все
.desktopфайлы в/usr/share/applications/. - Парсит
.desktopфайлы, используя необходимые инструменты, например,desktop-file-validateили библиотеки на Python для анализа содержимого файла. - Извлекает имя на подходящем языке, ориентируясь на локаль пользователя.
Как альтернатива, вам может пригодиться пакет app-install-data, который содержит метаданные о пакете в формате XML. Этот пакет может быть полезен для извлечения подобной информации в некоторых случаях.
Если вы хотите использовать whatis, ознакомьтесь с такими командами:
whatis <package-name>Учтите, что вам, возможно, придется дополнительно установить локализованные man-страницы, чтобы получить результат на нужном языке:
sudo apt install manpages-<locale>Итак, для того чтобы получить локализованное название программы, вам потребуется комплексный подход, сочетающий анализ .desktop файлов, возможно использование пакета app-install-data, а также интеграцию таких инструментов, как whatis для системных утилит. Этот метод требует осторожности и понимания, как система интернационализирует и локализуется, но в результате он позволяет получить полный и точный список приложений с профессионально представленными именами.
Следует помнить, что каждое приложение может обрабатывать локализацию по-своему, и наличие всех данных зависит от того, как оно скомпилировано и упаковано разработчиками. Таким образом, эффективное получение нужных данных требует как понимания работы самой системы, так и используемых инструментов.