(→Addon Packages (langpacks): don't necessarily prefer langcode to locale - may need langpacks for en_GB etc too) |
|||
| Line 3: | Line 3: | ||
The idea behind "langpacks" is to divide translations and 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. | The idea behind "langpacks" is to divide translations and 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. | ||
Packages that exist solely to contain additional language translations or content must be named in the format <pkgname>-langpack-<langcode>, where <pkgname> is name of the package the langpacks belong to and <langcode> is a valid language code from ''/usr/share/xml/iso-codes/iso_639_3.xml'' or | Packages that exist solely to contain additional language translations or content must be named in the format <pkgname>-langpack-<langcode>, where <pkgname> is name of the package 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's crucial to define following relation into the langpack definition in the spec file using the <code>Supplements:</code> tag as follows: | 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's crucial to define following relation into the langpack definition in the spec file using the <code>Supplements:</code> tag as follows: | ||
Revision as of 07:29, 22 January 2016
Addon Packages (langpacks)
The idea behind "langpacks" is to divide translations and 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.
Packages that exist solely to contain additional language translations or content must be named in the format <pkgname>-langpack-<langcode>, where <pkgname> is name of the package 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's crucial to define following relation into the langpack definition in the spec file using the Supplements: tag as follows:
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 change the spec file for such language. The snippet below shows the definition of one langpack for bs language by altering the spec file defined above.
Name: php-horde-Horde-Perms ... %package langpack-bs Supplements: (%{name} = %{version}-%{release} and langpacks-bs) %files langpack-bs /usr/share/pear-data/Horde_Perms/locale/bs/LC_MESSAGES/Horde_Perms.mo
%files ...