From Fedora Project Wiki
(Addon Packages (langpacks))
Line 1: Line 1:
 
== Addon Packages (langpacks) ==
 
== Addon Packages (langpacks) ==
  
Langpacks is a concept of dividing language contents (translations) into subpackages in the case the size of translation is enormous and/or the package is part of core image that should be minimal.
+
The idea behind "langpacks" is to divide translations into subpackages in the case that the size of translation is enormous or the package is part of a core image that should be minimal.
  
Packages that exist solely to contain additional language translations must be named in the syntax ''<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 match the langcode identifier used in the directory path by upstream for the language translation files.
+
Packages that exist solely to contain additional language translations must be named in the syntax <pkgname>-<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 match the langcode identifier used in the directory path by upstream for the language translation files.
  
Langpacks ecosystem does not need any procedural logic in form of plugin - it rather takes advantage of RPM weak and rich dependency features. Langpack dependencies are computed by package manager (DNF or PackageKit) so it's crucial to define following relation into langpack definition in the spec file:
+
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:
  
  Supplements: (<pkgname> = %{version}-%{release} and langpacks-<langcode>)
+
  Supplements: (%{name} = %{version}-%{release} and langpacks-<langcode>)
  
'''Example:'''
+
===Example===
  
 
Suppose you have a package with following spec file:
 
Suppose you have a package with following spec file:
Line 23: Line 23:
 
  Name: php-horde-Horde-Perms
 
  Name: php-horde-Horde-Perms
 
  ...
 
  ...
  <span style="color:green">%package langpack-bs
+
  <span style="color:green">%package bs
 
  Supplements: (%{name} = %{version}-%{release} and langpacks-bs)
 
  Supplements: (%{name} = %{version}-%{release} and langpacks-bs)
  %files langpack-bs
+
 +
  %files bs
 
  /usr/share/pear-data/Horde_Perms/locale/bs/LC_MESSAGES/Horde_Perms.mo</span><br />
 
  /usr/share/pear-data/Horde_Perms/locale/bs/LC_MESSAGES/Horde_Perms.mo</span><br />
 
  <span style="color:orange">%files</span>
 
  <span style="color:orange">%files</span>
 
  ...
 
  ...

Revision as of 23:28, 21 January 2016

Addon Packages (langpacks)

The idea behind "langpacks" is to divide translations into subpackages in the case that the size of translation is enormous or the package is part of a core image that should be minimal.

Packages that exist solely to contain additional language translations must be named in the syntax <pkgname>-<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 match the langcode identifier used in the directory path by upstream for the language translation 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 bs
Supplements: (%{name} = %{version}-%{release} and langpacks-bs)

%files bs
/usr/share/pear-data/Horde_Perms/locale/bs/LC_MESSAGES/Horde_Perms.mo
%files ...