Wielojęzykowość, Czekam na Wasze propozycje Opcje

[bim2]

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

[viking]

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

[bim2]

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")

[erix]

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.

[omeck]

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 :-)

[Pr0100]

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")

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

dziwisz się mu?

PS: przepraszam za OT

Ten post edytował Pr0100 7.07.2009, 02:08:43

[omeck]

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

dziwisz się mu?

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 ;-)

[erix]

do poleceń systemowych na serwerze... chyba malo ogolno dostępne, prawda? :-)

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

[omeck]

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

Jaki to promil wszystkich adminów? :-)

[erix]

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

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

[witul]

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.

[jolam]

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?

[erix]

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

[rzymek01]

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)

[jolam]

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

[GregoryW]

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

Dzięki za info

[nospor]

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?

[vokiel]

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.

[nospor]

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

[nasty]

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