История изменений
Исправление hobbit, (текущая версия) :
Я долго тупил, пытаясь вспомнить, в чём там глубокий смысл, наконец, догадался глянуть в собственные исходники и вспомнил. :)))
Логика такая. У программы есть каталог с переводами, путь к которому формирует функция LanguageManager::transPath(). Сейчас там лежат переводы как самого doublecontact, так и общекутешные.
И есть как минимум две ситуации, в которых это логично:
- сборки для ОС, в которых Qt не подтягивается для пользователя пакетным менеджером (как минимум, винда и макось);
- универсальные дистронезависимые сборки для линукса, не зависящие от пакетов с Qt (тот же AppImage, например).
А вот при традиционном опакечивании в deb/rpm/etc с применением «системной» Qt это, наверное, плохая идея, поскольку условный qt_ru.qm лежит как в каталоге с Qt, так и в каталоге с программой. Сам по себе он очень маленький (буквально полторы сотни байт на 1 язык), но когда пакет тащит несколько десятков языков, а кутешных программ в установленной системе много, это уже начинает огорчать и намекать на несовершенство нашего мира. :)
Возможно, стоит подумать о разделении на собственно transPath и qtTransPath. Первый всегда связан с программой, а второй в зависимости от сборки может указывать и на кутешный каталог. И подтягивать для арча qt5-translations, для дебиана qttranslations5-l10n, для других дистров аналогично.
Подумаю.
P.S. А с третьей стороны, я сейчас глянул содержимое этого самого qttranslations5-l10n, там что-то дофига всего, что пользователю не нужно, файлы справки, например. Так что может быть, существующий вариант и оптимален.
P.P.S. Другое дело, что в качестве источника копирования, получается, не всегда выступает /usr/share/qt?/translations/, как раз при статической сборке, где это копирование нужно в первую очередь, оно идёт каким-нибудь developer-префиксом. И вот это я, пожалуй, поправлю в ближайшее время…
Исправление hobbit, :
Я долго тупил, пытаясь вспомнить, в чём там глубокий смысл, наконец, догадался глянуть в собственные исходники и вспомнил. :)))
Логика такая. У программы есть каталог с переводами, путь к которому формирует функция LanguageManager::transPath(). Сейчас там лежат переводы как самого doublecontact, так и общекутешные.
И есть как минимум две ситуации, в которых это логично:
- сборки для ОС, в которых Qt не подтягивается для пользователя пакетным менеджером (как минимум, винда и макось);
- универсальные дистронезависимые сборки для линукса, не зависящие от пакетов с Qt (тот же AppImage, например).
А вот при традиционном опакечивании в deb/rpm/etc с применением «системной» Qt это, наверное, плохая идея, поскольку условный qt_ru.qm лежит как в каталоге с Qt, так и в каталоге с программой. Сам по себе он очень маленький (буквально полторы сотни байт на 1 язык), но когда пакет тащит несколько десятков языков, а кутешных программ в установленной системе много, это уже начинает огорчать и намекать на несовершенство нашего мира. :)
Возможно, стоит подумать о разделении на собственно transPath и qtTransPath. Первый всегда связан с программой, а второй в зависимости от сборки может указывать и на кутешный каталог. И подтягивать для арча qt5-translations, для дебиана qttranslations5-l10n, для других дистров аналогично.
Подумаю.
P.S. А с третьей стороны, я сейчас глянул содержимое этого самого qttranslations5-l10n, там что-то дофига всего, что пользователю не нужно, файлы справки, например. Так что может быть, существующий вариант и оптимален.
Исходная версия hobbit, :
Я долго тупил, пытаясь вспомнить, в чём там глубокий смысл, наконец, догадался глянуть в собственные исходники и вспомнил. :)))
Логика такая. У программы есть каталог с переводами, путь к которому формирует функция LanguageManager::transPath(). Сейчас там лежат переводы как самого doublecontact, так и общекутешные.
И есть как минимум две ситуации, в которых это логично:
- сборки для ОС, в которых Qt не подтягивается для пользователя пакетным менеджером (как минимум, винда и макось);
- универсальные дистронезависимые сборки для линукса, не зависящие от пакетов с Qt (тот же AppImage, например).
А вот при традиционном опакечивании в deb/rpm/etc с применением «системной» Qt это, наверное, плохая идея, поскольку условный qt_ru.qm лежит как в каталоге с Qt, так и в каталоге с программой. Сам по себе он очень маленький (буквально полторы сотни байт на 1 язык), но когда пакет тащит несколько десятков языков, а кутешных программ в установленной системе много, это уже начинает огорчать и намекать на несовершенство нашего мира. :)
Возможно, стоит подумать о разделении на собственно transPath и qtTransPath. Первый всегда связан с программой, а второй в зависимости от сборки может указывать и на кутешный каталог. И подтягивать для арча qt5-translations, для дебиана qttranslations5-l10n, для других дистров аналогично.
Подумаю.