Actually, this is subset of [Automatic (sub)package 
generators]( and an 
extension to
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 
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 `` and improve over the time. In 
`fedora` almost 1800+ spec files use `%find_lang` and we always can have 
opt-out option. Roughly 
 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]( 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]( 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`. 


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Rpm-maint mailing list

Reply via email to