(→Addon Packages (langpacks): bring back *-langpack-* and mention also "language content" in addition to translations) |
|||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
== Addon Packages (langpacks) == | == Addon Packages (langpacks) == | ||
The idea behind "langpacks" is to | The idea behind "langpacks" is to separate translations or language specific content into subpackages in the case that the size of the files is huge or the package is part of a core image that should be minimal. | ||
Subpackages that exist solely to contain additional language translations or content must be named in the form <pkgname>-langpack-<langcode>, where <pkgname> is the name of the package that the langpacks belong to and <langcode> is a valid language code from ''/usr/share/xml/iso-codes/iso_639_3.xml'' or from ''/usr/share/i18n/locales/''. Specifically, the langcode value used in the package name must agree with the langcode identifier used in the directory path by upstream for the translation or language files. | |||
The langpack ecosystem does not need any procedural logic in form of plugins. Instead it takes advantage of the weak and rich dependency features provided by RPM. The necessary dependencies are computed by package manager (DNF or PackageKit) so it | The langpack ecosystem does not need any procedural logic in the form of plugins. Instead it takes advantage of the weak and rich dependency features provided by RPM. The necessary dependencies are computed by the package manager (DNF or PackageKit) so it is essential to include the following <code>Supplements:</code> tag relation in the langpack package definition in the spec file: | ||
Supplements: (%{name} = %{version}-%{release} and langpacks-<langcode>) | Supplements: (%{name} = %{version}-%{release} and langpacks-<langcode>) | ||
| Line 19: | Line 19: | ||
... | ... | ||
In order to create langpacks for each language (''/usr/share/pear-data/Horde_Perms/locale/<language>/LC_MESSAGES/Horde_Perms.mo'' translations), you would need to | In order to create langpacks for each language (''/usr/share/pear-data/Horde_Perms/locale/<language>/LC_MESSAGES/Horde_Perms.mo'' translations), you would need to define a new subpackage for each package. The snippet below shows the definition of langpacks for ''bs'' and ''cs'' languages by altering the ''php-horde-Horde-Perms.spec'' file defined above. | ||
Name: php-horde-Horde-Perms | Name: php-horde-Horde-Perms | ||
... | ... | ||
<span style="color:green">%package langpack- | <span style="color:green"> | ||
Supplements: (%{name} = %{version}-%{release} and langpacks- | %define lang_subpkg() \ | ||
%package langpack-%{1}\ | |||
%files langpack- | Summary: %{2} language data for %{name}\ | ||
BuildArch: noarch\ | |||
Requires: %{name} = %{version}-%{release}\ | |||
Supplements: (%{name} = %{version}-%{release} and langpacks-%{1})\ | |||
\ | |||
%description langpack-%{1}\ | |||
%{2} language data for %{name}.\ | |||
\ | |||
%files langpack-%{1}\ | |||
%{_datadir}/pear-data/Horde_Perms/locale/%{1}/LC_MESSAGES/Horde_Perms.mo<br /> | |||
%lang_subpkg bs Bosnian | |||
%lang_subpkg cs Czech | |||
... | |||
</span> | |||
<span style="color:orange">%files</span> | <span style="color:orange">%files</span> | ||
... | ... | ||
Latest revision as of 10:48, 28 January 2016
Addon Packages (langpacks)
The idea behind "langpacks" is to separate translations or language specific content into subpackages in the case that the size of the files is huge or the package is part of a core image that should be minimal.
Subpackages that exist solely to contain additional language translations or content must be named in the form <pkgname>-langpack-<langcode>, where <pkgname> is the name of the package that the langpacks belong to and <langcode> is a valid language code from /usr/share/xml/iso-codes/iso_639_3.xml or from /usr/share/i18n/locales/. Specifically, the langcode value used in the package name must agree with the langcode identifier used in the directory path by upstream for the translation or language files.
The langpack ecosystem does not need any procedural logic in the form of plugins. Instead it takes advantage of the weak and rich dependency features provided by RPM. The necessary dependencies are computed by the package manager (DNF or PackageKit) so it is essential to include the following Supplements: tag relation in the langpack package definition in the spec file:
Supplements: (%{name} = %{version}-%{release} and langpacks-<langcode>)
Example
Suppose you have a package with following spec file:
Name: php-horde-Horde-Perms ... %files -f Horde_Perms.lang /usr/share/pear-data/Horde_Perms/locale/ ...
In order to create langpacks for each language (/usr/share/pear-data/Horde_Perms/locale/<language>/LC_MESSAGES/Horde_Perms.mo translations), you would need to define a new subpackage for each package. The snippet below shows the definition of langpacks for bs and cs languages by altering the php-horde-Horde-Perms.spec file defined above.
Name: php-horde-Horde-Perms ... %define lang_subpkg() \ %package langpack-%{1}\ Summary: %{2} language data for %{name}\ BuildArch: noarch\ Requires: %{name} = %{version}-%{release}\ Supplements: (%{name} = %{version}-%{release} and langpacks-%{1})\ \ %description langpack-%{1}\ %{2} language data for %{name}.\ \ %files langpack-%{1}\ %{_datadir}/pear-data/Horde_Perms/locale/%{1}/LC_MESSAGES/Horde_Perms.mo
%lang_subpkg bs Bosnian %lang_subpkg cs Czech ... %files ...