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
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to