[Rpm-maint] [rpm-software-management/rpm] RPM Translation subpackage(s) (#1276)
Sundeep Anand
notifications at github.com
Thu Jun 18 12:38:01 UTC 2020
Actually, this is subset of [Automatic (sub)package generators](https://github.com/rpm-software-management/rpm/issues/329) and an extension to https://github.com/rpm-software-management/rpm/issues/310.
However, creating this to have contained discussions.
Currently most of the RPM packaged applications ship translations with them.
And, translations take up more space (_even than fonts_) in workstations, fedora silverblue, and others.
Hence there could be a need to limit this considering minimization initiative(s).
After some investigations it seems feasible to go step by step.
1. To separate translations from main `PKG` and create a sub-package, for example - something like, `%{name}-translations` as a weak dependency (`Supplements: %{name} = %{version}-%{release}` not sure about `arch`). Certainly we may leverage on `find_lang.sh` and improve over the time. In `fedora` almost 1800+ spec files use `%find_lang` and we always can have opt-out option. Roughly [something](https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/94) how `debuginfo subpackages` works. Furthermore, this feature should work only when we have translations in `%{buildroot}`.
2. Next step could be to create translation sub-package(s) grouped by `language_id`. For example, suppose a package has mo files for `ja`, `pt`, `pt_BR`, `zh_CN`, `zh_TW`, `zh_HK`, `it_IT`, and `de` locales, then 5 sub-packages would be created namely `%{name}-translations-ja`, `%{name}-translations-pt`, `%{name}-translations-zh`, `%{name}-translations-it` and `%{name}-translations-de`. Here `%{name}-translations-zh` shall contain 3 mo files. With this approach we may limit number of sub-packages (_lesser RPM metadata_) and need not to implement locale-mapping/fallback. Moreover, this may enable us to tie up these sub-packages to langpacks meta-package installation. (_and may [help](https://teams.fedoraproject.org/project/silverblue/us/116) in flatpak locales creation too_) Here, we did not call them `langpacks` because, `langpacks` may also contain fonts, IMEs, dictionaries etc. These may live as a weak dependency? I am not sure but there could be a role of `system active locale` to suggest sub-package(s) to users while installation - may be a [dnf](https://github.com/rpm-software-management/dnf) thing though! Base locale would be "C".
This is an attempt to kick off discussions around this and move towards appropriate approach doing it in `rpm`.
thanks!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1276
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200618/f9c2c982/attachment.html>
More information about the Rpm-maint
mailing list