Forum PHP.pl

Witam,
Od jakiegoś czasu piszę duży projekt i doszedłem do wybierania języku. Chciałbym poznać Wasze zdanie jak ma działać taki system wielojęzykowości strony. Pobuszowałem po internecie i oto, co wymyśliłem.

• Pliki.
  Trzymamy pliki językowe w plikach. Każdy język ma osobny katalog, każdy ma pliki o takiej samej nazwie jak reszta języków, w plikach tablice o takich samych kluczach. Wybieramy odpowiedni język, include odpowiedniego pliku i print.
• Teksty w bazie danych.
  Tworzymy dwa obiekty. Jeden (może być traktowany jako filter) pobiera dane z bazy danych i przerzuca je do klasy o nazwie np. LangWrapper. Używając magicznych metod __get() pobieramy tekst z klasy i __set() gdy nie ma potrzebnego tekstu należy do stworzyć
• Open Power Template

Byłbym wdzięczny za propozycje rozwiązań.
Wojtek.

Myślę ze dobrym rozwiązaniem są pliki. Stosuje sie je w wielu cmsach i projektach.
Tłumaczenia w bazie danych to według mnie zaśmiecanie db i w dodatku majac wiele jezykow robi sie syf i przedluza sie czas wyszukiwania.
Tutaj nalezy zadac pytanie jak stworzyc taki plik. Czy ma byc to plik php w ktorym definiuje się zmienne/stałe czy zwykły plik tekstowy typu



Nie wiem co jest bardziej wydajne, jednak jesli chcemy zeby naszych jezykow nikt nie "podgladal" no to php

jeżeli w projekcie masz zamiar używać OPT, to ja na twoim miejscu użył bym opt'owego i18n ;]

Smarty: {config_load file="text.conf" section=$language} no i posprzątane

Ja korzystam z modifiera SMARTY

[HTML] pobierz, plaintext 
{"Jakis_tam_komunikat"|lang:"admin"}
[HTML] pobierz, plaintext 

Przepuszczam to przez modifier lang z paramtrem admin.

A ja się bawię "słownikiem" - mam plik lang_pl.php, lang_en.php itp..... w bazie trzymam dla jakiego użytkownika jaki plik załadować (oczywiście to może później sobie zrobić). W plikach tych mam tablicę $Lang:

[PHP] pobierz, plaintext 
<?php
$Lang['Enter'] = 'Wejście';
$Lang['Exit'] = 'Wyjście';
.
.
.
?>
[PHP] pobierz, plaintext 

i tak plik normalnie includuje....

Ja z kolei napisałem sobie plugin do Smartego. Templejty tworzę normalnie, używając naszego narodowego języka. Mam również plik XML, który nazywa się identycznie jak nazwa szablonu czy też modułu szablonu i zawiera tłumaczenia tekstów z templejta w wielu językach.

Np.:

Moduł szablonu: menu.mod.tpl


Plik XML zawierający tłumaczenie:


Plugin Smartego po skomiliowaniu szablonu zamienia wszystkie teksty, które są uwzględnione w pliku XML (sekcja source) na żądany język.

Ma to dwie ogrome zalety:
- w połączniu z keszowaniem parsowanie xml-u nie jest aż tak uciążliwe dla systemu
- mój tłumacz nie musi znać się na php (aplikacja), HTML (templejty); ba! nawet nie zagląda do tych plików - ma swój katalog, do którego wrzuca pliki XML

Ten post edytował eMartio 7.04.2006, 10:17:59

I ma taką wadę, że języki są różne i różną mają gramatyke... twoim sposobem czesto zdażyć się może, że nie da się w prosty sposób przetłumaczyć danego zdania.

http://developer.gnome.org/projects/gtp/tr...-gnome/x22.html - pliki .po i ich dekoder napisany przez Bastiona to całkiem dobre rozwiązanie.

Fajnie też rozwiązał to NuLL, ale pliki .PO są bardzo popularne, istnieje też wiele programów służących do ich edycji, co upraszcza tworzenie nowych wersji językowych. gTranslator i KBabel, for example.

wydaje mi się, że to jest dobry pomysł. ja tak robię.

choć lepszym sposobem jest napisanie

$lang = array(
'czesc' => 'eloza',
'czlowiek' => 'ziom'
);

może się czepiam, ale sposób pisania TomASS'a jest jednak bardzo nieefetywny. php to nie C w php'ie najlepiej robić wszystko w jednej komendzie. choć szacun dla Niego, Jego squadu i Jego samicy za sposób robienia słownika (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) podoba mi się (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

z resztą ten sposób jest użyty także w sugarCRM.

Ten post edytował 3rdeye 12.04.2006, 15:11:27

Ja ze swojej strony mogę polecić draft i18n z Mojavi 4, całość prezentuje się iście interesująco.. niestety w chwili obecnej serwer Mojavi leży..

Ja mam strony wielojezykowe zrobione na podstawie bazy danych i dosłownie zero tekstu w kodzie html. Struktura plikow php wyglada podobnie jak bym smarty zastosowal.
Jeden minus to ze jest duzo zapytan do bazy i moze stanowic obciazenie przy wiekszym serwisie. Ale wtedy juz prosto mozna zastosowac cachowanie stron.

Ja osobiscie korzystam z plikow ini. Plik jezykowy globalny, + pomniejsze pliki jezykowe np: do konkretnego modulu. W Smarty korzystam z postfilter ktory podmienia odpowiednie ciagi znakow na wartosci np: [lang:mod_news,dodaj] na "Dodaj newsa"

ja wczytuje zawartosc pliku ini dla wybranego jezyka do tablicy (parse_ini_file) a potem po prostu:
{$lang[costam][costam]}

Moim zdaniem prawda znowu leży po środku - wydaje mi się, że pliki są bardzo dobrym rozwiązaniem, jeśli chodzi o teksty formularzy itp. Jednak co, jeśli ktoś będzie chciał tłumaczyć całe artykuły, znajdujące się w bazie? Wtedy najlepszym rozwiązaniem byłoby połączenie systemu pliki+baza.
Wydaje mi się, że można by stworzyć tabele osobno dla każdego języka, np. en_articles, pl_articles itp., bo trzymanie tych danych w jednej tabeli nie miałoby raczej najmniejszego sensu, skoro i tak są one wykorzystywane naprzemiennie, a nie razem.

PS. Nie jedźcie po mnie za bardzo, bo ostatnio w php coś pisałem chyba z pół roku temu:) I wesołych świąt wam życzę.

Ja osobiście trzymam wszystko w jednej tabeli, w której mam kolumnę "Lang" określającą w jakim języku jest dany wiersz czyli np:

[SQL] pobierz, plaintext 
ID | Tytul | Tresc | Lang
[SQL] pobierz, plaintext 

Potem w zalezności od wybranego języka wybieram potrzebne dane np.:

[SQL] pobierz, plaintext 
SELECT * 
FROM tabela
 WHERE Lang=$_GET['lang']
[SQL] pobierz, plaintext 

Jeżeli natomiast chodzi o stałe teksty typu: "Więcej", "Strona głowna" to trzymam je w XML - ach gdzie struktura plików jest następująca:

parsuję XML z wykorzystaniem PEAR::XML_Unserializer i podrzucam do smartów gdzie wyświetlam to:

[PHP] pobierz, plaintext 
<?php
{$Translation.StronaGlowna}
?>
[PHP] pobierz, plaintext 

Obecnie pracuję nad manadżerem do tłumaczeń - coś na zasadzie kompilacji XML - a do pliku w którym byłaby zserializowana tablica z tłumaczeniami. I jeżeli XML jest nowszy niż skompilowane dane to wtedy kompiluję jeszcze raz. Jeżeli nie to odczytuję i podstawiam zserializowaną tablicę

Teraz tak myślę i doszedłem do wniosku, że twoj podejście jest chyba lepsze od mojego (jeśli chodzi o trzymanie w bazie, bo xml i pliki to dla mnie to samo - wszystko zależy od możliwości serwera itp) - zakładając, że chcę dodać kolejny język, przy twoim podejściu mogę (przynajmniej teoretycznie) dodać go z poziomu panelu, nie grzebiąc w strukturze baz.

A co wy na to (suma kilku pomysłów):

[PHP] pobierz, plaintext 
<?php
   function array_path_insert(&$array, $sep, $path, $value)
   {
	   $path_el = split($sep, $path);
 
	   $arr_ref =& $array;
 
	   for($i = 0; $i < sizeof($path_el); $i++)
	   {
		   $arr_ref =& $arr_ref[$path_el[$i]];
	   }
 
	   $arr_ref = $value;
   }
 
$trans=array();
 
foreach(file("translations/{$lang}.txt") as $line)
{
  $chunks=explode("=", $line);
  define("TXT_".array_shift($chunks), implode("=", $chunks));
  /* define("TXT_".array_shift($chunks), eval(implode("=", $chunks))); // tak jakby chciać tutaj włożyć jakąś logikę */
  /* define("TXT_".array_shift($chunks), str_replace('\n', "\n", implode("=", $chunks))); // tutaj jakby nie chcieć interpretować wszystkiego */
  /* można też zrobić preg_replace z tablicami */
  /* XXX: Ależ mi nachodzi pomysłów. Dla tablicowców-smartowców następna wersja. (funkcje znalazłem w komentarzach do manuala) */
  array_path_insert($trans, '.', array_shift($chunks), implode("=", $chunks));
}
$smarty->cośtam('lang', $trans);
?>
[PHP] pobierz, plaintext 

A plik translacji wyglądałby oczywiścieTaka synteza paru pomysłów - prosta i szybka implementacja.
Do drugiej metody (tej z tablicami), wyglądałobyto oczywiście analogicznie

To oczywiście tylko dla małych tekstów dla tworzenia innojęzycznych wersji serwisów. Dla mniejszycg napisów, dla których nie chcemy marnować cennych id w bazie danych. Bo co do większych napisów zgadzam się z przedmówcami.

Ten post edytował Jabol 16.04.2006, 21:40:21

To nie lepiej użyć poprostu plików ini ?
Podczas moich praktyk w firmie gdzie brałem udział w tworzeniu aplikacji w springu (java) był stworzony plik (nie pamiętam jakie miał rozrzeszenie może .properties czy cuś) ale wyglądał on niej więcej :

main.welcome = Witam
main.menu = Menu
itp.

A co, jeśli w tłumaczonym tekście wystąpi znak "=" bądź przełamanie linii?