[klasa PHP5] Klasa wspierająca wielojęzykowość, Klasa w teorii ma ułatwić dodawanie wielojęzykowych elementów tekstowy Opcje

[everth]

Poniższa klasa powinna pomóc w tworzeniu wielojęzykowych stron.

Przy projektowaniu wzorowałem się na podobnej funkcji w bibliotece Qt4 - gdzie metoda tr() ułatwia znacznie tworzenie templatek z tłumaczeniami, właściwie bez ingerencji w kod. Moja klasa próbuje to (trochę nieporadnie, ale cóż) zaimplementować w PHP. Główne założenia:

• niezależność od źródła danych (wydzielony interfejs dla modelu danych z tłumaczeniami)
• łatwość użycia w kodzie (szybka skrótowa funkcja $U())
• automatyczne tworzenie bazy na podstawie wpisów w kodzie (w trybie appendMode dodajemy unikatowe ID i (opcjonalnie) tłumaczenie)
• dobra dokumentacja - na obecnym etapie podstawowa dokumentacja w phpDoc
• elastyczność - klasa w zasadzie projektowana była dla statycznych elementów tekstowych (napisy na przyciskach, napisy w stopce, itd.), ale ponieważ są to ciągi tekstowe to z łatwością można sobie dostosować np. do przechowywania ścieżek do plików graficznych z różnymi napisami, przy odrobinie wysiłku można w ten sposób dodawać nawet artykuły wielojęzykowe (po prostu generujemy ID dla artykułu i zawijamy w funkcję $U() - np. $U('12334') - później tworzymy wersje językowe dla tego ID)

Przykładowa baza w sql na początku ma dwie kolumny - id z identyfikatorami oraz kolumnę aktualnego języka (np. "pl_PL"), dodając nową kolumnę - dodajemy nowy język, według mnie ułatwia to tworzenie i edycję arkusza z tłumaczeniami np. w Excelu lub Calcu (po przerzuceniu tabeli w CSV). Przykładowa struktura:

[SQL] pobierz, plaintext 
CREATE TABLE  `Translations` (
  `id` varchar(40) CHARACTER SET latin1 NOT NULL,
  `pl_PL` mediumtext, -- nie jestem w stanie określić jak długie mogą być ciągi tekstowe tutaj
  `en_GB` mediumtext,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8
[SQL] pobierz, plaintext 

Przykładowe użycie:

[PHP] pobierz, plaintext 
//Z użyciem trybu appendMode (dodajemy UIDy oraz przykładowe tłumaczenia w polskim)
$locale = new Translation($pdo);
$locale->setLang('pl_PL');
$locale->appendMode(1); //włączamy appendMode
$locale->setup();
 
echo <<<EB
<ul>
<li>{$U('M_HOME','Główna')}</li>
<li>{$U('M_ABOUT','O nim')}</li>
<li>{$U('M_PORTFOLIO','Portfolio')}</li>
</ul>
EB;
 
//Bez appendMode - sam odczyt UIDów (w przypadku braku pusty string)
$locale->__destruct(); //niestety obiekty Translation nie tolerują żadnego ponownego wywołania bez ręcznego zniszczenia poprzedniej instancji - a ponieważ obiekt tworzy co najmniej 2 referencje do siebie to metoda unset() zawodzi, niestety to obecnie najsłabsze ogniwo - nie powinno się tworzyć więcej niż jedną instancję w przebiegu skryptu!
$locale = new Translation($pdo);
$locale->setLang('pl_PL');
$locale->setup();
echo <<<EB
<ul>
<li>{$U('M_HOME')}</li>
<li>{$U('M_ABOUT')}</li>
<li>{$U('M_PORTFOLIO')}</li>
</ul>
EB;
[PHP] pobierz, plaintext 

Kod źródłowy Translation wraz z klasami pomocniczymi jest pod tym linkiem

[everth]

Aleś po mnie pojechał (IMG:style_emoticons/default/smile.gif) Więc teraz postaram się choć trochę usprawiedliwić (to jest wersja pre-pre-alfa - a nie wyglancowany produkt ostateczny)

1. WTF?! Poczytaj o właściwościach statycznych.

   To jest najbardziej niepodobająca się mi część kodu. Co do właściwości statycznych - one raczej nie znajdują tu zastosowania, ja wyprowadzam tą referencję na zewnątrz obiektu (choć nie powinienem) tylko po to żeby móc się do niej odwołać w funkcji wrapperze $U(), tylko po to. Szukałem sposobu który pozwoliłby określić aktualną zewnętrzną referencję obiektu z wewnątrz obiektu (żeby użyć w funkcji wrapperze) - nic nie udało mi się znaleźć. Stąd ten hack z wyprowadzeniem dodatkowej referencji w GLOBALS (i to przez niego mam problemy z usuwaniem obiektu Translation). Istniała też możliwość przekształcenia obiektu w singletona (teraz uważam że tak byłoby nawet lepiej), tylko po drodze uznałem że niektórzy mogę chcieć mieć kilka instancji obiektów obok siebie, z różnymi językami -> tak wynikły z tego problemy, których już nie zdążyłem/nie chciało mi się dziś rozwiązywać

2. Czy mi się dobrze wydaje, czy do pobrania każdej wartości wywoływane jest zapytanie do bazy danych? (w translacji DB)

   
   tu miałem zagwozdkę, bo rzeczywiście zastanawiałem czy nie pobrać całości jednym zapytaniem. Ostatecznie zdecydowałem o użyciu spreparowanych zapytań i bindingu. Dlaczego? Bo nie mam pojęcia jak wielkie mogą być te tabele, a ostrożność każe mi zakładać najgorsze. Jak ktoś chce to z łatwością napisze sobie własne LocaliseDbOne (lub rozszerzy obecną klasę) posługujące się jednokrotnym zapytaniem

3. @access nie stosujesz jak piszesz dla php5
   Jeżeli zwracasz egzemplarz tej samej klasy możesz dać @return self

   phpDoc - to jest moje pierwsze użycie po zapoznaniu się z dokumentacją (IMG:style_emoticons/default/smile.gif)

4. W preperestatement masz "podwojony" kod dla update.
   Po co robisz addslashes skoro możesz skorzystać z bindowania wartości, które takie "zabezpieczenie" Ci załatwia?

   - to wynik nieprecyzyjnego czyszczenia kodu - pierwsze to przeoczenie, drugie to zaszłość po wcześniejszym rozwiązaniu (na bindowanie przestawiłem się już pod koniec)

5. A teraz puenta. Jaka jest różnica w stosowania twojej klasy od gettext?

   - no to mnie zastrzeliłeś, bo rzeczywiście nie wiedziałem o tym rozwiązaniu (ogólnie o całej tej kategorii w manualu), jedyne co mam na swoją obronę to to, że ja mogę składować dane w bazie (a gettext składuje je w plikach *.mo - a one nie są czasem binarne?), lub w czymkolwiek do czego napiszę klasę. Jak znów będę miał trochę czasu to pomyślę nad gettext - może nawet da się go wepchnąć w interfejs TranslationModel

Ten post edytował everth 7.08.2010, 07:51:04