Wordpress jest najlepszym przykładem. Ja także nie używam gettext(), jedynie się na tym wzoruje. Poszukać w google wystarczy "i18n php" i wyskoczy wiele różnych rozwiązań. Nawet na tym forum jakieś znalazłem

Ewentualnie w PHP 5.3 jest coś takiego http://pl2.php.net/manual/en/class.messageformatter.php

Tyle, że na php 5.3 na serwerach troche trzeba poczekać Kolega robił update php wczoraj, ale na trójkę się nakłonić nie dał... nie wiem czemu ;/ ("bo wyszła dzisiaj")

Dziwisz się? Osobiście np. Fx-a zaktualizuje za może miesiąc; obie paczki są jeszcze za świeże, nie zostały wystarczająco przetestowane.

Wyjdzie 5.3.1, będzie można się nieco pobujać. [; Ale nie zmieni to faktu, że w ogóle na edycję 5.3 trzeba jeszcze poczekać co najmniej pół roku.

Tak, do zalet gettext należy to, że jest lekki, szybki praktycznie ogólno dostępny... ale przekonaj klienta, żeby pobrał sobie z serwera pliczek z tłumaczeniami, pobrał i zainstalował sobie dodatkowe oprogramowanie np. poedit, wyedytował, a następnie wysyłał na serwer. Można też zrobić interfejs do aplikacji i generować np poprzez jakiś panel admina... jest jendno 'ale' - generowanie plików z tlumaczeniami, co wiąże się z dostepem do poleceń systemowych na serwerze... chyba malo ogolno dostępne, prawda? :-)
Dodatkowo: http://us2.php.net/manual/en/ref.gettext.php#50424 ;-)

Osobiście szczęśliwie korzystam z Zend_Translate oraz pliczków CSV - lekkie, proste, szybkie, wygodne i można bez zadnych przeszkód napisac do tego gui :-)

http://packages.debian.org/search?keywords...amp;section=all

dziwisz się mu?

PS: przepraszam za OT

Jeśli ktoś na gwałt potrzebuje paczki z PHP5.3 do Debiana, to jest dostępna na: http://www.dotdeb.org/2009/07/03/php-5-3-0...r-debian-lenny/. Koniecznie należy przeczytać "What are the changes from Dotdeb?"

PS: przepraszam za OT +1 ;-)

Serwery, których admini wiedzą, co to znaczy suPHP + jail dla procesu, nie mają zablokowanych poleceń systemowych.

Jaki to promil wszystkich adminów? :-)

Jakoś we wszystkich hostingach, z którymi mam do czynienia, polecenia systemowe nie są zablokowane.

Więc śmiem twierdzić, że to nie jest promil.

A ja stosuje podzial na baze i pliki:
np w cmsie zrobilem sobie ze jezyk jest subdomena serwisump, en.domena.pl czy de.domena.pl.
Szablony stron, teksty i inne elementy pisane sa osobno pod kazdy jezyk.
A jesli chodzi o statyczne teksty typu "Zapisz", "To pole jest wymagane" - wiadomo, pliki.

Chciałam się poradzić w jednej sprawie dotyczącej spraw wielojęzykowości. Mam stronę w kilku językach, ale podstrony w tych językach niewiele różnią się od siebie. Strona zawiera głównie grafiki. To czy lepiej tłumaczyć fraz na tej stronie czy całą stronę. To znaczy, czy lepiej w kodzie tej strony, między grafikami mieć np $lang['tlumaczonytekst'], czy trzymać w bazie treść strony dla każdego języka i ładować odpowiednią stronę w zależności od wyboru usera? Teraz stosuje pierwsze rozwiązanie ale może tabela kolumnami textid, contentpl, contenten? Czy powinnam zastosować drugie rozwiązanie czy pozostac przy pierwszym?

pozdrawiam Jola

Zapomniałam napisać wprost, przy tej mojej metodzie z jedna stroną i tłumaczeniem fraz mam dużo małych zapytań do bazy. Gdybym zmieniła metodę to miałabym jedno duże zapytanie. Ale musiałabym mieć dwie treści i modyfikacje wprowadzać dwa razy i pamiętać o nich. Co lepsze?

A przeczytałaś cały wątek?

W Twoim przypadku 1. sposób wydaje się lepszy, tylko od razu pobieraj wszystkie langi (dużo ich na pewno nie masz) albo zapisuj je w pliku (lub plikach jak chcesz podzielić na moduły)

Oczywiście, że przeczytałam ten wątek, co za pytanie. Chcę się jedynie upewnić. Sposób 1 wydaje mi się wygodniejszy, dlatego go wybrałam. Ale obawiałam się o wydajność. Bo to kilka/kilkanaście zapytań do bazy, zamiast jednego dużego.

pozdrawiam Jola

Korzystał ktoś kiedyś ze Smarty Multilanguage? Jeśli tak - jaką to ma wydajność?

Dzięki za info

Pytanko/dylemat:

Zaznaczam od razu, że nie chodzi mi o artykuły/newsy. Chodzi mi o komunikaty w stylu: "dane zapisano", "Dodaj komentarz" etc.

Do tej pory miałem to w plikach .ini i było wszystko ok. Stanąłem jednak przed problemem, gdzie będę musiał dać klientowi możliwość edycji tych danych w panelu serwisu. Babranie się tu w edycję plików i do tego sensownie to grupować już nie jest takie fajne i przyjemne jak wówczas, gdyby to było wszystko bazie.
Do tego dochodzi problem, że ja mogę uaktualniać moduły i wraz z modułem mogą się uaktualnić pliki z tekstami. Jeśli klient by coś już zmodyfikował to ja przy aktualizacji bym mu to nadpisał.

A więc możliwe dwa rozwiązania:
1) pliki .ini
piszę jakiś systemik do aktualizacji danych. minusem będzie to, że gorzej się go będzie pisało niż dla DB
gdy klient zmodyfikuje jakiś zestaw danych, tworzony jest dodatkowy plik .ini z jego zmianami.
Gdy system będzie musiał odczytać jakiś tekst, szuka go najpierw w plikach zmodyfikowanych a jeśli tam go nie będzie, szuka w moich oryginalnych.
Jak widać trochę latania przy pobraniu tekstu tu będzie. Powiedzmy że bym zastosował cache to może by było znośnie.

2) tłumaczenia w bazie
O optymalność się nie martwie bo bym cacheowal.
Napisanie systemiku do edycji - w miarę proste.
Gdy ja dostarcze aktualizacje modułu z nowymi tekstami to wystarczy wykonać parę insertów i po sprawie - nic nikomu nie nadpiszę.
Minus - całe zarządzanie mam już na plikach .ini i bym musiał do bazy wrzucić wszystkie tłumaczenia jakie do tej pory mam.


Co Wy sądzicie o tym? Mieliście już do czynienia z taką właśnie sytuacją, że trzeba dać klientowi narzędzie do modyfikacji tekstów i mieć na uwadze kolejne aktualizacjie oprogramowania wraz z tekstami?

Jeszcze nie miałem takiej konieczności, jednak IMHO łatwiej byłoby w bazie.

• Przy dodawaniu nowych wpisów, nie ma ryzyka, że nadpisze się już istniejące.
• Ewentualne zmiany większej ilości wpisów są szybsze i łatwiejsze.
• Dochodzi możliwość kontroli co kto zmienił, szybkiego wyszukania wpisów edytowanych przez klienta.
• Dzięki powyższemu, w trakcie aktualizacji można wyświetlić wpisy, które były edytowane przez klienta, i zestawić mu je z propozycjami tymi od aktualizacji.
• Nie wiem, czy będziesz potrzebował, ale w przypadku zdalnych poprawek, dostęp do db jest według mnie wygodniejszy niż wysyłanie plików via @, czy przez ftp.
• Może się chyba zdarzyć, że aktualizacja rozszerzy dany wpis o coś nowego, wtedy poprzednia zmiana klienta nie będzie już aktualna i zestawienie mu danych, które mogą wymagać poprawy, lub po prostu zaakceptowania nowej wersji byłoby wygodne.

Co do dodania już istniejących tłumaczeń do bazy, to w końcu tylko jednorazowa operacja. Ważne aby później było łatwiej korzystać z systemu.

W zasadzie, czy zrobisz to na ini, czy db, to i tak spełni swoje zadanie. Różnice mogą być w czasie potrzebnym na napisanie, a będą w przypadku późniejszych zmian.

Rozpisałeś mi tutaj zaawansowany system w DB: akceptacja, zestawienia.... aż tak bardzo nie chciałem szaleć
No nie rozwiałeś moich wątpliwości. To teoria, z której zdaję sobie sprawę. Mam nadzieję, że ktoś praktycznie miał z tym do czynienia.

edit:
dobra, robie na bazie. na plikach już mam to trzeba zadbac o nowe doświadczenia

A może zastosuj bazę i zrób małego bota co Ci wrzuci wszystko z tych .ini do bazy?

juz przepisałem ręcznie

Wszyscy się zastanawiają jak robić tłumaczenie, ale najprościej moim zdaniem zrobić podobnie jak ma wordpress. Sam tworzyłem teraz czterojęzyczny serwis i wychodzi, że najprościej jest dać np. w templatkach

Dzięki temu jest nawet możliwość poprawy literówek już na poziomie bazy danych, nie plików bo kluczem jest md5(). Tak więc, dzięki temu jestem w stanie poprosić kilkoro ludzi do poprawiania literówek i tworzenia tłumaczeń bez konieczności szukania tego po plikach.

Dla statycznych tekstów najlepiej jest użyć gettext. A dla trzymanych w bazie to l18n

Hmm, ja miast gettext korzystam z własnego sytemu z racji tego, że były problemy z tym gettext. Cachowało mi jakimś cudem plik i nie było możliwośći wgrania najnowszwego pliku. Co do danych typu newsy, mam kolumnę lang i później w zapytaniach where :langW: tzn. where lang = 'pl'

Dokładnie, to żadna sztuczka ta wielojęzyczność. Mi tam gettext działa bez problemu, tylko to trochę upierdliwe jest z tymi tłumaczeniami ;p trzeba się opisać jak głupi

@bim2: chyba osobną tabelę łączoną w relacji 1-1 (z id oraz językiem), a nie samą kolumnę

No tak. Zależy co masz. Jak mam stronę statyczną gdzie występuje tylko Tytuł i Treść to mam jedną tabelę, bo tytuł też tłumaczymy A id takie samo.

nie wiem czy ktoś już to pisał :F

ja mam różne języki zapisane w tablicach php i je wrzucam do templatki tak jak pozostałe zmienne. Kwestia pobrania odpowiedniego pliku językowego

jmail także tak miałem, ale po n serwisach to jest niewydajne w trakcie pisania tego. Musisz dodać sobie do tablicy wpis, później w templatkach {$lang.user} Tylko nie wiesz ci kryje się pod user jakbyś chciał coś zmienić/dodać.

Gettext jest najlepszym wyjściem i radzę Ci się na to przerzucić.

no jak tam kto uważa. dla mnie to jest wygodne i wydajne nie miałem jakoś probolemów do tej pory i jakoś tam działało ale przejrzę to co proponujesz i zobaczymy

Ok przeczytalem caly watek wywnioskowalem troche z niego tworzac wlasny "Fw" mysle ze przyda sie standartowa implementacja wielojezykowosci.

Dla stalych tresci zrobie to porostu tak:

Mam komponent news i jego opis autor,data,tresc i tytul i katalog jego widokow czyli:



No i na podstawie zmiennej sesyjnej wczytam odpowiedni widok z odpowiedniego katalogu(implementacja wczytywania w klase View a jezyku w innej)

Wydaje mi sie to wygodne,elastyczne i shcludnie wyglada.




Co do tresci np zawsze naszych news'ow zrobie to tak jak pokazal to @rzymek01 w poscie http://forum.php.pl/index.php?s=&showt...st&p=476814 podpunkt:



Zaprezentowany rozniez przez Kayne.




Co jednak dla wyswietlania bledow w kilku jezykach bo tego nie zrozumialem albo nie doczytalem jak to osiagnac powiedzmy ze ktos chce sie zalogowac jak w przypadku danego jezyka wyswietlic komunikat w odpowiednim jezyku myslalem by zrobic katalog errors w katalogu widoku danego komponentu/pluginu a nim tablice typu:

[PHP] pobierz, plaintext 
 
$err['pl']['badpwd'] = 'Zle haslo';
 
$err['eng']['badpwd'] = 'Bad login';
 
[PHP] pobierz, plaintext 

Wtedy w kontrolerze komponentu/pluginu robic:

[PHP] pobierz, plaintext 
 
if(blad podczac logowania) $view -> AddVar('error', $lang -> errors[$lang -> getLang()]['badpwd']);
 
[PHP] pobierz, plaintext 

Wydaje mi sie rozsadne czy sie myle moze zabardzo zamotane i zaduzo jest kalogow plikow czy cos?

Ja byłbym nadal za i18n, nawet dla błędów czyli $lang->get('Wrong login.');

Czyli jak i gdzie zapisywac bledy?

Bo nie rozumiem.

Nigdzie. Piszesz błąd jaki wystapił a tłumaczenie działa na zasadzie tłumaczenia całych fraz. Tj. ja mam w bazie danych tabelę langs z kolumnami hash|pl|en|pt|es Hash to md5 frazy, a reszty się chyba łatwo domyślić. Wszędzie piszę domyślnie po polsku czyli jak mam błąd to robię

[PHP] pobierz, plaintext 
 
$form->addError($lang->get('Niepoprawne hasło.'));
[PHP] pobierz, plaintext 

I później sprawdzam czy w bazie jest hash = md5($fraza) Jeśli nie ma dodaję ją do bazy z hashem i wypełnionym polem pl. Później tłumaczenie to zmiana en pt lub es.

Wole to trzymac w plikach i zrobic tak jak ja to rozpisalem.

P.S ale dzieki za nastepna metode

Po 5 zleceniach odechciewa się szukania języków po plikach, sprawdzania poprawiania. Po przerzuceniu się na ten sposób odczujesz wielką ulgę Naprawdę, przestaw się już teraz będzie mniej problemów później :]

Kazdy komponent/plugin bedzie mial katalog errors a w nim plik z o nazwie takiej samej jak nazwa komponentu/pluginu dane bede zapisywane tak jak podalem wyzej wiec na to samo wychodzi czy pliki czy baza jeden kit.

Tak samo biblioteka tez bedzie mogla miec wlasne bledy w roznych jezykach jesli zajdzie taka potrzeba np lib do upload'u/download'u

Pomyśl, że chcesz później dodać kolejny język i dać możliwość grupie tłumaczy tłumaczenia tego. Jak to rozwiążesz?

Dam im plik z errors i do tego pliki widokow a dane dynamiczne jak news'y etc.... to wiadomo.

Taaak, rozdziel to dla kilku tłumaczy Nie będzie tak łatwo. Zresztą przy n modułach kopiuj sobie wszystkie pliki itd.

Mysle ze przy latwych stronach metoda moze sie sprawdzic jak nie zawsze bede mogl zmienic implementacje klasy language i tyle

Trochę zeszliście Panowie z tematu...

A co do tematu jak tym zarządzać, to... nie ma tematu - przygotowanie prostej aplikacji, która udostępniłaby jakiś w miarę przyjazny tłumaczowi interface to kwestia powiedzmy godzin, by było to w miarę dopracowane.

Jeżeli natomiast chodzi o format przechowywania danych w plikach tekstowych to wartym rozpatrzenia formatem jest oparty o XML XLIFF. Z własnego doświadczenia niewiele mogę powiedzieć o współpracy z tłumaczami przy wykorzystaniu tego formatu, ale ponoć istnieje trochę gotowych aplikacji do operowania na tym i inne firmy chętnie z tego korzystają.

Nie wiem na ile moje pytanie pasuje do reszty postów wątku ale:

Czyli lepiej tworzyć adresy z oznaczeniem języka jako subdomena czy nie?

www.strona.com/en/super/hiper/podstrona
czy
www.en.strona.com/super/hiper/podstrona



pozdro

Co do subdomen czy ogolnie jezyka w url wiem jedno jest to o tyle lepsze ze poprzez url uwzgledniamy odrazu jezyk strony dla user'a bez zadnego wybierania tzn jak wysle link strony php.pl koledze ten nie zna jezyka pl wiec musi wybrac jezyk poprzez podanie mu adresu w stylu www.php.pl/index.php/en/ lub www.en.php.pl user nie musi juz nic zmieniac.

Wedlug mnie zalezy tez ile subdomen masz do dyspozycji i ile jezykow chcesz zaimplementowac.

Jednak sam wyslucham opini innych by wiedziec w czym jeszcze moze sie przydac.

Język w ogóle nie musi być widoczny w adresie. Dla użytkownika nie będzie to miało znaczenia, bo przed wyświetleniem czegokolwiek trzeba sprawdzić jakie języki akceptuje przeglądarka usera, w jakiej kolejności itd. A jak był na naszej stronie to odczytujemy jego ciasteczko. Czyli ten sam adres pokaże stronę w różnych językach w zależności od użytkownika. Ale myślę, że dla google lepiej rozróżniać język w adresie. Choć mechanizm pozostaje ten sam: użytkownik trafia na stronę strona.com i tam jest przekierowywany na np strona.com/pl/. Ale właśnie czy lepiej język do adres dodac jako subdomenę czy po nazwie domeny? Co o tym myślicie?

Ja jestem za subdomenami, ale tylko ze względów estetycznych. Nie widzę różnicy między pl.strona.com en.strona.com a strona.com/pl/ strona.com/en/

Dlaczego? Będę chciał koledze przesłać linka do jakiegoś artykułu w wersji angielskiej... No niestety będę musiał napisać: wejdź na URL i zmień sobie język na angielski, zamiast: wejdź na URL.

Język powinien być w adresie,a moim zdaniem najlepiej jak jest w subdomenie, szczególnie dla wyszukiwarek : szukamy na angielskim google mamy en.adresstrony.xx a na polskim pl.adresstrony.xx itp więc moim zdaniem jest to największa przewaga tego typu rozwiązania + indeksowanie treści, google będzie miało ten sam adres przy zmianie treści więc zaindeksuje tą treść raz (w przypadku braku języka w adresie).

P.S. Nie jestem w tym specjalistą i to są tylko moje luźne spostrzeżenia
P.S. Szczerze chciałbym usłyszeć pogląd specjalisty od pozycjonowania na temat : "Językowość, a wyszukiwarka."

A może jednak w ogóle nie uwzględniać języka w adresie strony? Wystarczyłoby sprawdzić jaki jest język przeglądarki i na podstawie tego poprzez sesje albo ciasteczka automatycznie wyświetlać treść w odpowiednim języku. I też user nie musi nigdzie klikać, chyba, że zechce. Wtedy wszystkie linki przychodzące byłyby do jednej strony a nie byłyby rozdzielone na dwie strony o różnych adresach. Ale co z indeksacją strony? Czy google będzie raz indeksować dla en a raz dla pl?

pozdro

Będzie zmienna treść co jest trochę bez sensu. Można wykorzystać język przeglądarki, ale nie jest do pewne rozwiązanie. Najlepsze to dwie oddzielne pod/strony - łatwe zarządzanie i obie z nich mogą mieć różną zawartość.