Nerdblog.pl - Wielojęzykowa strona w Kohanie 3.x

Wielojęzykowa strona w Kohanie 3.x

Podczas pracy nad jednym projektem dostałem zadanie - zrobić stronę w wielu językach. Ponieważ problem jest dość ciekawy, postanowiłem trochę o nim popisać^[1]

W przypadku tworzenia mniej dynamicznej strony internetowej zawierającej jednak panel administracyjny, możemy mówić o tłumaczeniu dwóch najważniejszych elementów: tych w bazie danych i tych na stronie. Na początek skupmy się na tych na stronie, a później przejdziemy do bazy danych.

Strona - tak, to trzeba przetłumaczyć

Ponieważ Kohana jest lekkim i mocno modyfikowalnym frameworkiem, do każdego zadania możemy podejść na kilka sposobów. Ma to swoje wady - praca z innym developerem potrafi być upierdliwa jeśli mamy już swoje 'sprawdzone' metody, ale ma też wiele zalet, choćby to, że można dobrze doprofilować sobie narzędzia do potrzeb. Tak samo jest z wielojęzykowością^[2]. Domyślnie Kohana do tego typu zadań posiada klasę i18n, która pozwala na wykorzystanie __() (gettext). Przykładowo po utworzeniu odpowiednich plików językowych fraza

__("Hello world!")

Może zostać wyświetlona jako Hello world! w języku angielskim oraz Witaj świecie! w języku polskim.

To rozwiązanie niestety nie nadaje się do stron internetowych. Możecie mnie oczywiście zlinczować, skoczcie po smołę, a ja rozwalę kilka poduszek, ale taka jest prawda. Większe bloki tekstu bardzo niewygodnie modyfikuje się tym sposobem, ponieważ drobna zmiana składni pociąga za sobą modyfikację tego samego w N plikach (gdzie N to ilość języków).

Cwani programiści rozwiązują to na przykład w ten sposób:

__("main_page.description")

To rozwiązanie też jest paskudne. Dlaczego? Ponieważ wymaga od nas pamiętania --nastu albo nawet --set słów-kluczy. Ciężko potem się połapać gdzie co jest i jak właściwie do cholery miało działać. Nadaje się to na niewielką stronę, ale przy większym projekcie, a już w ogóle modułowym zaczyna robić się burdel. Poza tym co jeśli ma to przyjmować jakieś wyrazy lub zmienne liczbowe? Nagle tworzy nam się tona dodatkowych podkluczy + wersje językowe (np. 1 bułka / 2 bułki / 5 bułek) itd.

Więc jak to ugryźć?

Wspominałem już, że Kohana jest modyfikowalna, prawda? W takim razie się zabawimy. Stworzymy sobie N widoków na strony zawierających odpowiednio przetłumaczone i poprawnie obsługujące wielojęzykowość podstrony, a żeby się nie bawić z doklejaniem co chwilę I18n::lang()^[3] zmodyfikujemy nieco klasę View.

Schody? Nie, raczej winda.

Jeśli jesteś początkujący w Kohanie, powyższe wyda ci się przerażające. Ale jak to, modyfikować libkę należącą do core Kohany? Uspokajam - system/ pozostanie nieruszone, pamiętacie, kaskadowy system plików, no nie? ;)

Zacznijmy od utworzenia pliku application/classes/view.php i wpisania do niego podstawowego szkieletu:

<?php class View extends Kohana_View
{
 
}

Ten brak ?> to nie błąd, to konwencja zapożyczona z Fuela. Możesz też zwrócić uwagę, że nie trzymam się do końca Kohanowskiej konwencji i robię enter przed otwarciem klamerki - tak, ugryź się, takie Javowanie jest nieczytelne.

Wracając do tematu - musimy się teraz chwilę zastanowić ^[4] do czego dążymy. Chcemy, żeby klasa przy pobieraniu widoku szukała czy istnieje wersja językowa i jeśli tak pobierała ją. Strukturę katalogów w view/ możemy więc utworzyć dla uproszczenia jako

view
  - view/en-us
  - view/pl-pl

Teraz myślimy jeszcze raz, aż się mózg grzeje - w którym momencie powinniśmy doklejać ścieżkę? Doklejanie jej bezczelnie do nazwy widoku spowoduje niewyświetlenie go w przypadku gdy coś będzie niedotłumaczone, a przecież chcemy mieć ładny fallback, prawda?

Nurkujemy więc w dokumentację i kod źródłowy i znajdujemy - View::set_filename() ^[5]. Metoda ta korzysta z Kohana::find_file() do znajdowania odpowiedniego pliku i zwraca jego ścieżkę. Do naszych celów będzie idealna. Otwieramy więc nasze application/classes/view.php i piszemy:

protected static $default_lang = "en-us";
 
public function set_filename($file)
{
   if (($path = Kohana::find_file('views', I18n::lang().'/'.$file))       === FALSE &&
       ($path = Kohana::find_file('views', self::$default_lang.'/'.$file)) === FALSE)
   {
      throw new Kohana_View_Exception('The requested view :file could not be found', array(
         ':file' => $file,
      ));
   }
 
   $this->_file = $path;
   return $this;
}

Co właśnie zrobiliśmy? Jeśli masz jakiekolwiek pojęcie o PHP prawdopodobnie już widzisz, dla reszty czytającej do dla funu - utworzyliśmy sobie zmienną zawierającą domyślny język ^[6] i dodaliśmy sprawdzanie czy plik istnieje dla danej wersji językowej.

Proste, co?

...

Nie no, chyba nie myślisz, że tak to zostawimy? Bez żartów, to nie jest kolejny nastoletni blogasek o pr0 programowaniu, żeby zostawiać tego typu half-assed rozwiązania.

Zapewne do tej pory zdążyłeś już wyczuć wszystkie możliwe wady tego rozwiązania i ostrzysz już klawiaturę, żeby mi dowalić. Przede wszystkim - nie zostawiliśmy miejsca na szablony, które są wspólne dla obu wersji językowych (można je wrzucać po prostu do en-us, ale to bardzo nieeleganckie rozwiązanie). Poza tym każda zmiana struktury strony powoduje modyfikację N podstron. Brudne, niewygodne itd.

Więc po co właściwie pokazałem to rozwiązanie? Żeby nakierować na właściwe tory ;)

Moglibyśmy jeszcze bardziej przerobić set_filename, dodać jeszcze jeden fallback, tym razem do domyślnego katalogu. ^[7], ale to nie rozwiąże problemu struktur. Nie, możemy zrobić coś lepszego.

Wykorzystać widoki w roli czystego i18n.

Tłumaczenie w widoku?

Sposób rozwiązania jest banalny. Wycinamy w cholerę nasze set_filename (chciałem tylko pokazać, że się da tak zrobić) i wracamy do punktu wyjścia. Tym razem tworzymy jednak pełnoprawną, osobną metodę w klasie View, która posłuży nam jako punkt bazowy do tłumaczeń, tym razem bazując jednak zarówno na View::set_filename() jak i View::factory():

public static function i18n($file = NULL, array $data = NULL)
{
   if ((Kohana::find_file('views', I18n::lang().'/'.$file)) !== FALSE)
   {
      return new View(I18n::lang().'/'.$file, $data);
   }
   else
   {
      return new View(self::$default_lang.'/'.$file, $data);
   }
}

Teraz mamy ładną statyczną metodę, która pobierze nam odpowiedni element z języka, zwróci fallback jeśli istnieje lub po prostu wywali się (całkiem słusznie) z błędem jeśli nie znajdzie ani jednego, ani drugiego. Możesz sobie dodać jeszcze taki myk przy zwracaniu fallbacka, żeby wykrywać problemy na przyszłość:

Log::instance()->add(Log::WARNING, 'Translation for :lang for file doesn't exist: :file', array(
   ':lang' => I18n::lang(),
   ':file' => $file
));

Ostatnie szlify

Pozostaje jedna kwestia - jak tłumaczyć pojedyncze elementy? Przecież nie będziemy tworzyć całego nowego widoku gdy musimy w szablonie przetłumaczyć np. przycisk "Zaloguj się" na górze strony. W tej kwestii sprawdza się już po prostu gettext. Wiadomo, że mając w ręku młotek wszystko wygląda jak gwóźdź, ale warto dopasowywać narzędzia do potrzeb.

A jeśli komuś przeszkadza, że ma część tekstu w view/, a część w i18n/ - opakuj to sobie w moduł. W modules tworzysz katalog, np translations/, po czym wrzucasz tam po kolei katalogi PL, EN itd, a w bootstrap.php dodajesz je jako moduły:

'translation_en'  => MODPATH.'translation/EN',  
'translation_pl'  => MODPATH.'translation/PL',  

Kaskadowy system plików to fajna sprawa, co? :)^[8]

Pozostaje jeszcze jedna sprawa:

Wielojęzykowość danych w bazie

Na ten problem filozofowie i programiści szukali rozwiązania od lat: jak sprawić, żeby pola w bazie były w wielu językach? Istnieją trzy podstawowe filozofie:

Pierwsza to osobna baza danych - strony są od siebie pod tym względem niezależne i mogą zawierać różne dane. Względnie podwersją tego są różne nazwy tabel, ale idea jest identyczna. Powoduje to jednak problemy gdy dane mają mimo wszystko być takie same - łatwo to wszystko rozsynchronizować i generalnie jest paskudnie.

Druga to osobne klucze w bazie. Zamiast N tabel o nazwie tabela_LANG mamy N kluczy w stylu name_LANG1, name_LANG2, name_LANG3, description_LANG1, description_LANG2, description_LANG3. Dawniej stosowałem to rozwiązanie, ale jest bałagarniaskie jak diabli. Przede wszystkim struktura bazy się komplikuje, poza tym nieprzyjemnie się pracuje przy więcej niż dwóch językach.

Ostatnie rozwiązanie zaproponował mi bodajże ^argasek, ale nieco je zmodyfikowałem: osobna tabela zawierająca tłumaczenia. Można do tego podejść na dwa sposoby, jeden moim zdaniem gorszy, drugi chyba lepszy, chociaż wymagający więcej pól w bazie.

Rozwiązanie pierwsze wygląda następująco: tworzymy tabelę zawierającą pięć (lub cztery, można olać ID i z product_id zrobić index, ale Kohanowy ORM tego nie lubi) pola:

id :          int (PRIMARY, auto_increment)
element_id :  int (INDEX)
field :       varchar [255]
translation : varchar [255]
lang :        enum [pl, en]

Następnie traktujemy to jako worek na tłumaczenia, wrzucając po kolei pola w stylu:

id | element_id |  field  |     translation    |  lang
 1 |          1 |  'name' |  'Udko z kurczaka' | 'pl-pl'
 2 |          1 |  'name' |    'Chicken leg'   | 'en-us'

Jak widać robi to paskudny bałagan i średnio mi się podoba, dlatego odpowiednio je zmodyfikowałem. Idea zostaje praktycznie identyczna tylko zamiast pól field i translation tworzymy tyle pól, ile ma oryginalna tabela i wpisujemy tam wszystkie wartości, np:

id | element_id |       'name'      |         'description'       |  lang
 1 |          1 | 'Udko z kurczaka' |  'Jest chrupiące i pyszne'  | 'pl-pl'
 2 |          1 |   'Chicken leg'   | 'It's crispy and delicious' | 'en-us'

Od razu lepiej, prawda? Brakuje jeszcze jednego: wygodnego wykorzystania tego. Przecież nie będziemy się ciągle partolić z pobieraniem tego typu rzeczy z bazy, ani tym bardziej przeciążać co chwilę ORM-a pierdołami. Dlatego stworzymy sobie prościutki wrapper.

Na początek tworzymy model, dla konwencji nazywając go element_locale^[9] (a poprzednią tabelę oczywiście element_locales):

<?php class Model_Element_Locale extends ORM
{
   protected $_belongs_to = array
             (
                 'element' => array('model' => 'element'),
             );
 
}

Następnie przydzielmy go do modelu Element:

<?php class Model_Element extends ORM
{
   protected $_has_many = array
             (
                 'locale' => array('model' => 'element_locale')
             );
 
}

A następnie przeładujmy sobie Element::__get(), żeby było nam łatwiej^[10]:

public function __get($column)
{
   if(in_array($column, array('name', 'description')))
   {
      return $this->locale->where('lang','=',i18n::lang())->find()->$column;
   }
 
   return parent::__get($column);
}

Dlaczego nie przeładowujemy przy okazji Element::__set() ? Żeby przypadkiem czegoś nie spieprzyć - wystarczy, że zapomnimy zmienić język podczas zapisywania w dowolnym miejscu kodu - klapa. Poza tym tłumaczenia przy ich edycji powinny być w mniejszym lub większym stopniu od siebie niezależne.

Jeśli komuś bardzo zależy i nie spodziewa się skakania między językami w trakcie pracy skryptu, powyższe może jeszcze skeszować:

protected $_locale;
 
public function l10n()
{
   if( !($this->_locale instanceof ORM))
   {
      $this->_locale = $this->locale->where('lang','=',i18n::lang())->find();
   }
   return $this->_locale;
}
 
public function __get($column)
{
   if(in_array($column, array('name', 'description')))
   {
      return $this->l10n()->$column;
   }
 
   return parent::__get($column);
}

Gdyby się tak uprzeć, można pokusić się jeszcze o automatyczne pobieranie właściwych pól w in_array. Ponieważ $_table_columns w ORM-ie jest typu protected, musimy utworzyć odpowiednią metodę w Element_Locale:

protected static $_non_locale_columns = array('id', 'element_id');
 
public function locale_columns()
{
   $keys = array_keys($this->_table_columns);
   foreach(self::$_non_locale_columns as $column)
   {
      unset($keys[$column]);
   }
   return $keys;
}

A następnie zmodyfikować poprzednią metodę:

public function __get($column)
{
   if(in_array($column, ORM::Factory('element_locale')->locale_columns() ))
   {
      return $this->l10n()->$column;
   }
 
   return parent::__get($column);
}

Ktoś się zaraz zapyta - ale zaraz, dlaczego ORM::Factory, a nie $this->l10n() ? Bo l10n korzysta $this->locale (czyli z __get) i mamy paradoks. Niestety nie mam w tej chwili pomysłu jak to lepiej rozwiązać. Jeśli komuś bardzo zależy, może skorzystać z Database::list_columns() i napisać dzięki temu locale_columns() statycznie, ale moim zdaniem to już będzie za dużo kombinowania. No i można znowu keszować ...no ale bez przesady ;)

Cóż, w tym jakże króciutkim jak na dzisiejsze standardy (wiem, jestem złośliwy, przepraszam) wpisie wspomniałem o wielojęzykowości na stronach internetowych. Oczywiście tematu nie da się wyczerpać i zapewne znajdzie się kilka osób, które będą miały lepszy pomysł jak rozwiązać podane problemy - zapraszam do dyskusji, może się czegoś nowego nauczę ;)

Uff, chyba wracam do pisania na Nerdblogu.

Edit (18.07.2011)

Ostatecznie zdecydowałem się na rozwiązanie, które proponowałem w komentarzach poniżej:

public function __get($column)
{
	try
	{
	    return parent::__get($column);
	}
	catch(Exception $e)
	{
	    return $this->l10n()->$column;
	}
}

Ma ono tylko jedną, "poważną" wadę - lepiej jest używać go, gdy mamy pewność, że wszystkie zależności są w odpowiednim miejscu. W innym wypadku debugowanie jest straszliwie upierdliwe. Niestety Kohana nie zwraca żadnego fajnego Exception, które można filtrować, a parsowanie getMessage() za pomocą wyrażeń regularnych to hack, dlatego pozostaje pilnować kodu, a dopiero później dodać lokalizację ;)