Wielojęzykowość, Czekam na Wasze propozycje Opcje

[rzymek01]

racja, mój błąd

nie chciałem już mieszać, bo na początku chciałem zrobić lang_id

[Blodo]

Kolejny odkop no ale..

Ja uzywam dwoch tabel: jedna dla tzw. metadata czyli ID, kategoria; druga dla samych tlumaczen. Przypisuje im jezyk za pomoca lang_id w drugiej tabeli, I wyciagam z bazy za pomoca JOINa. Ogolnie ten skrypt co mam automatycznie wybiera jezyk przegladarki dla uzytkownika, lub - jezeli nie ma takiego jezyka w systemie - wybiera jezyk domyslny (angielski).

Zakladajac ze w bazie danych nie zawsze bedzie tlumaczenie dla kazdego artykulu w jezyku uzywanym w tym momencie przez uzytkownika, jak moznaby sformulowac zapytanie do SQLa tak aby przy wyciaganiu artykulow dla danej kategorii wyciagalo wszystkie artykuly w wersji jezykowej uzytkownika lub w wersji jezyka domyslnego jezeli poprzednie sie nie powiodlo? Poki co moim rozwiazaniem jest SELECT na wszystkie lang_id, i potem sprawdzanie co wyswietlic a co nie za pomoca PHP, ale to troche badziewne rozwiazanie IMO. Ktos sie natknal na taki problem?

[Sedziwoj]

@Blodo
Może coś w tym stylu:

[SQL] pobierz, plaintext 
SELECT * FROM base_data AS b LEFT JOIN lang_data AS l ON ( l.base_data_id = b.id AND l.lang_id = x) LEFT JOIN lang_data AS l2 ON (l2.lang_id = y AND l.id IS NULL);
[SQL] pobierz, plaintext 

x - id wybranego języka
y - id domyślnego języka
To jest na JOIN, ale mam parę pomysłów na inne rozwiązania, tylko raczej nie wydajniejsze.

[Blodo]

Hmm, dobry pomysl. Co prawda trzeba w php potem sprawdzic ktore pole z tabeli nie jest "NULL", no ale i tak lepiej niz bylo. Dzieki ci za to.

[Sedziwoj]

Hmm, dobry pomysl. Co prawda trzeba w php potem sprawdzic ktore pole z tabeli nie jest "NULL", no ale i tak lepiej niz bylo. Dzieki ci za to.

No to zrób jeszcze jedno użyj CASE... i wtedy w php nic nie robisz, tylko wyświetlasz.

[Albitos]

Wybaczcie, że odgrzewam temat. Baardzo długo zastanawiałem się nad rozwiązaniem wielojęzykowości w moich skryptach. Końcowo doszedłem do wniosku, że idealnym rozwiązaniem będzie wykorzystanie systemu wbudowanego w OPT oraz kilku ciekawych ulepszeń. Po pierwsze, wszystkie stałe językowe przechowywane są w kategoriach niezależnych od czegokolwiek. Grupujesz jak chcesz, potem wczytujesz te grupy. Wczytanie jednej stałej z grupy powoduje wczytanie wszystkich z danej grupy.

Załóżmy, że mamy takie grupy:

• navigation
• contact
• home
• global

Teraz struktura plików:
languages/pl/
navigation.php
contact.php
home.php
global.php
languages/en/
navigation.php
contact.php
home.php
global.php

Każdy plik PHP składa się z tablicy $lang, która zawiera stałe. Dlaczego akurat tablica, a nie jakiś XML/YAML? Otóż z bardzo banalnego powodu. W pewnym momencie, kiedy pracowałem nad grą internetową (http://orodlin.pl) okazało się, że stałych odpowiedzialnych za niektóre akcje jest bardzo dużo (w jednym pliku ponad 500), natomiast wykorzystywana jest tylko jedna. Ładowanie wszytkich takich danych przy pomocy parsera byłoby całkowicie bezcelowe - marnotrawstwo pamięci.
Dlatego zamiast tablicy stworzyłem obiekt implementujący interfejs ArrayAccess, który pobiera potrzebne stałe prosto z bazy danych. Muszę przyznać, że jestem z takiego rozwiązania bardzo zadowolony. Wszystkie stałe są pogrupowane w logiczne kategorie, w razie konieczności przechowania większych ilości danych, używam odpowiedniego obiektu bez modyfikowania samego systemu językowego.
Pozostał tylko jeden zasadniczy problem - rozbicie wszystkich stałych na kilka plików wymusza wczytanie za każdym razem kilku plików. Ten problem rozwiązałem, używając cache. Wszystkie stałe, o ile nie pochodzą z dynamicznych tablic (tych obiektów implementujących ArrayAccess) zapisuję przy pomocy jednej wielkiej zserializowanej tablicy i zapisuję w pliku. Każda akcja w kontrolerze ma taki swój własny plik. W ten sposób kilka plików ładowanych jest tylko za pierwszym razem.

Jestem w trakcie pisania pluginu do OPT który będzie realizował taki system. Mam nadzieję, że wszystkim się spodoba. Tymczasem chciałbym poznać wszystkich opinie, co sądzą o takim rozwiązaniu.

EDIT: Co do danych dynamicznych, w Orodlinie istnieje założenie, że gra = jeden język. W innych projektach, gdy muszę mieć różne wersje językowe dynamicznych danych (np. artykułów), po prostu w tabeli dodaję pole określające język.

Ten post edytował Albitos 19.08.2008, 15:19:07

[tomek_swat]

mam pytanie jak sobie radzicie z wersją językową przechwyconych wyjątków, w każdej klasie jest:

[PHP] pobierz, plaintext 
<?php
throw new exception (..)
?>
[PHP] pobierz, plaintext 

i jak to uzależnić od wyboru języka, ja trzymam wszystkie klasy w folderze /classes i właśnie rozwiązanie tego problemu sprawia mi kłopoty?
pzdr

[Crozin]

Ale w jakim celu tłumaczyć wyjątki? One są raczej informacją dla programu/skryptu, a nie użytkownika.

Możesz:
1) Przeklazać już odpowiednio przetłumaczony wyjątek:

[PHP] pobierz, plaintext 
<?
throw new Exception(myTransolator('invalidABCDE'));
?>
[PHP] pobierz, plaintext 

2) Napisać właśną klasę wyjątków, która robi to co kod powyżej, ale już wewnątrz siebie:

[PHP] pobierz, plaintext 
<?
class MyException extends Exception{
  public function __construct($msg = '', $code = 0){
    $this->msg = myTranslate($msg);
    $this->code = $code;
  }
}
?>
[PHP] pobierz, plaintext 

Ale jeszcze raz zapytam: po co?

[tomek_swat]

załóżmy, że mam klasę Config, która jest Singletonem i pobiera z pliku .ini wersję jęzkową systemu
jezyk = "pl" i w zależności od tego klasa Lang, parsuję odpowieni plik .ini z folderu gdzie znajdują się odpowiednie wersję językowe
co jeśli w pliku settings.php parsowanym przez klasę Config, użytkownik wpiszę język, który nie jest uwzględniony w folderze w którym znajdują się wersję językowe? pozostaję wypluć wyjątek, tu właśnie pojawia się w problem w jakim on ma być języku i jak ten język zaimplementować w klasie Lang i Config?
pzdr

[Sedziwoj]

Nie zawsze wyjątki są najlepsze, powinieneś sprawdzić czy dany język istnieje jeśli nie to ustawiany jest domyślny. Jeśli gdzieś w serwisie jest użyte coś, czego nie ma w pliku językowym to jest błąd, i taka informacja też nie musi być rozpowszechniana po prostu wymuszenie przez moduł językowy załadowania informacji o błędzie/braku informacji, to już jest statyczna informacja niezależna od błędu, no i log dla nas aby dojść co się sypnęło.

[test_next]

Witam,
tak pobieżnie przeglądając odpowiedzi nie widziałem sposobu z definiowaniem zmiennych językowych jako stałe np. define('HELLO_WORLD","Hello world"); echo HELLO_WORLD. Co o tym sądzicie?
Pozdrawiam

[erix]

Mało przenośne. Co w sytuacji, gdy np. stała konfiguracyjna będzie nosiła tę samą nazwę jak językowa?

Poza tym, wg Twojego schematu idealny byłby gettext" title="Zobacz w manualu PHP" target="_manual.

[test_next]

tak tylko aplikacja ma być przenośna, a gettext nie wszędzie jest zainstalowany.
No i jeszcze wchodzi w grę licencja tego typu rozwiązań - odpada GPL.

[viking]

To zainteresuj się Zend Framework (i zanim napiszesz coś o gettext przeczytaj dokładnie dokumentację).

[test_next]

To include GNU gettext support in your PHP build you must add the option --with-gettext[=DIR]
przeczytałem i ?

[bim2]

Nie miałem siły przeglądać całego watku, ale moim zdaniem najlepszym wyjściem jest podany 3 posty wyżej przez erixa sposób. gettext" title="Zobacz w manualu PHP" target="_manual Oczywiście jakaś nakładka na to co by zapamiętała jakie frazy używam w systemie i generacja pliku .po A później już z górki :]

Przez 2 lata używałem zwykłych zmiennych includowanych do klasy języków i metodą get() pobierania ich. Ale to nie jest wyjście. Ciężko się połapać w tym wszystkim.

[viking]

To include GNU gettext support in your PHP build you must add the option --with-gettext[=DIR]
przeczytałem i ?

Mówiłem o ZF.

The Zend_Translate Gettext Adapter is not implemented using PHP's gettext extension. You can use the Gettext Adapter even if you do not have the PHP gettext extension installed. Also the Adapter is thread-safe and the PHP gettext extension is currently not thread-safe.

[test_next]

viking: ok, ale aplikacja jest dosyć rozbudowana i nie ma już sensu przenosić jej na zend'a...

[Crozin]

Zapewne da się ten komponent "wyciąć" z niego i stosować osobno.

[erix]

tak tylko aplikacja ma być przenośna, a gettext nie wszędzie jest zainstalowany.

Zobacz sobie, jak jest emulowane to rozszerzenie w Wordpressie.