Czasem "lokalizuje" się programy - tak, by zachowywały się nieco inaczej w zależności od środowiska, od ustawień "locales". Pakiety RPM również mają pewne możliwości w tej dziedzinie - podstawowa rzecz którą można "zlokalować" to opisy pakietu, można też od ustawień języka uzależnić listę instalowanych plików - można np. instalować niemieckojęzyczną wersję dokumentacji tylko wtedy, gdy użytkownik deklaruje używanie tego języka. Pozwala to na stworzenie pakietów które będą przedstawiały się użytkownikowi w jego ojczystym języku i które nie będą instalować niepotrzebnych mu plików - np. francuskich czy japońskich stron manuala. Przy odpowiednim nakładzie pracy można stworzyć uniwersalny pakiet "wielojęzyczny".

Zacznę może od opisów pakietów. Co można przełożyć na nasz język? Standardowo tłumaczy się pola Summary: i Description:, bo one zawierają opisowe teksty. Pola Name: raczej się już nie zmienia. Niektórzy tłumaczą też nazwy zawarte w polu Group:...

Ja nie tworzę "wielojęzykowych" pakietów, bo nie mam takiej potrzeby. Mam z góry ustalone preferencje językowe więc nie muszę programować tutaj żadnych alternatyw. Ale jeśli chcesz tworzyć pakiety dla szerszej publiczności, to obowiązuje jedna zasada - podstawowym językiem musi być angielski. Pozostałe są tylko dodatkami, które mogą zakryć podstawowe teksty. Tak więc wszystkie pola, jak Group: czy też Summary: muszą być wypełnione w języku angielskim. Tak samo należy bezwzględnie instalować oryginalną, anglojęzyczną dokumentację. Bo nie wszystkie języki da się "obsłużyć", nie dla każdego da się dostarczyć opisy czy dokumentację - więc musi być jakiś język "uniwersalny" - i w świecie współczesnej informatyki jest to angielski. Tak samo zresztą, jak w wielu innych współczesnych dziedzinach - chemii czy medycynie. Oczywiście jeśli nie masz aspiracji tworzyć uniwersalnych pakietów dla wszystkich nacji tego świata możesz po prostu pominąć ten rozdział.

Zacznę od fragmentu preambuły. Zwykła, podstawowa może wyglądać np. tak:

Summary:  General Purpose Mouse support for Linux
Name:     gpm
Version:  1.20.1
Release:  %{_rc}.2
License:  GPL
Group:    Daemons

Załóżmy, że chcemy teraz dodać wsparcie dla języka polskiego i niemieckiego. Będzie to wyglądało tak:

Summary:     General Purpose Mouse support for Linux
Summary(de): Allgemeine Mausunterstützung für Linux
Summary(pl): Uniwersalny daemon myszy w Linuksie

Name:        gpm
Version:     1.20.1
Release:     %{_rc}.2
License:     GPL
Group:       Daemons
Group(de):   Dämonen
Group(pl):   Daemony

Jak widać, jest to tutaj bardzo proste - jeśli chcę dostarczyć jakiegoś pola w jego przetłumaczonej wersji, to po prostu po nazwie pola, w okrągłych nawiasach, podaję kod języka jakiego opis dotyczy. A jak to działa w praktyce? RPM magazynuje sobie wszystkie wersje tych pól. Pola bez określonych języków (tutaj anglojęzyczne) są zawsze polami "domyślnymi". RPM wewnętrznie operuje właśnie na nich, ale w interakcji z użytkownikiem sprawdza, czy nie ma przypadkiem dostępnych odpowiednio "zlokalizowanych" wersji - jeśli tak, to prezentuje je zamiast wersji domyślnej. Jeśli użytkownik ma lokale ustawione na np. "pl" ale pakiet nie oferuje tekstów w wersji (pl), to zobaczy wersję domyślną. Jest to prosty i skuteczny sposób.

Poza lokalizowaniem "nagłówków" pakietu można też zrobić to samo z wpisami plików w %files, ba. Robi się to dyrektywą/makrem %lang. Przyjmuje ono jeden argument - kod języka. Linijka która jest prefiksowana makrem %lang będzie "ignorowana" przy budowaniu pakietu, ale odezwie się przy instalacji. Pliki oznaczone za pomocą %lang zostaną zainstalowane tylko jeśli locale środowiska będą uwzględniały dany język. Np.:

%files
%defattr(0644,root,root,0755)
%{_mandir}/man*/*.gz
%lang(pl) %{_mandir}/pl
%lang(de) %{_mandir}/de

taka definicja spowoduje zainstalowanie "ogólnych" manuali, a jeśli środowisko będzie uwzględniało (jako języki "obsługiwane" przez zmienne $LC_*) język polski lub niemiecki, to dodatkowo zainstalowane zostaną wersje zlokalizowane manuali.

I jeszcze coś: standardowo w dystrybucji rpm-4.1 znajduje się skrypt find-lang.sh, podpięty pod makro %find_lang. Ma on w domyśle przeszukać drzewko plików w %{buildroot} i znaleźć wszystkie pliki "lokalizacyjne" (zależne od języka) po czym spreparować plik tekstowy zawierający ich listę razem z odpowiednimi dyrektywami %lang na potrzeby włączenia do sekcji %files (pamiętasz, %files może włączyć sobie "polecenia" z zewnętrznego pliku tekstowego). Wszystko to powinno ułatwić pracę, ale tak nie jest, niestety. Skrypt wydaje się być niedokończony, np. wykrywa i odpowiednio dzieli pliki z tłumaczeniami *.mo oraz zlokalizowane części online-help środowiska Gnome, ale np. w ogóle ignoruje różne wersje językowe manuali, co sprawia że pakując te pliki i tak musisz odwalać spory kawałek roboty ręcznie. Ale mimo wszystko skrypt ten jest interesującym materiałem który możesz chcieć dostosować do swoich potrzeb. Albo zupełnie zignorować, twój wybór. Ja w każdym razie nie będę tego teraz opisywał, skrypt jest dobrze okomentowany.