Wielojęzykowość, Czekam na Wasze propozycje |
Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.
Wielojęzykowość, Czekam na Wasze propozycje |
14.05.2007, 19:39:55
Post
#61
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
Ja bym szybciej jedną tabele `article` i w niej kolumny:
id|lang_id|... PRIMARY KEY (id,lang_id) bo obie są unikalnym identyfikatorem, zakładając że mam powiązania miedzy artykułami w różnych językach. A wybieranie to z automatu dodawany jeden warunek, jak nie ma rekordu z takimi warunkami to nie ma, a nie tworzy bóg wie ile tabel. -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
15.05.2007, 09:56:56
Post
#62
|
|
Grupa: Przyjaciele php.pl Postów: 1 112 Pomógł: 20 Dołączył: 10.04.2005 Ostrzeżenie: (0%) |
@Sedziwoj - masz oczywiście rację, zdaje się, że trochę się zapędziłem :)
Jedna tabela z oznaczeniem języka dla każdego rekordu to faktycznie bardziej elegenackie rozwiązanie. pozdr. |
|
|
24.12.2007, 00:23:58
Post
#63
|
|
Grupa: Zarejestrowani Postów: 663 Pomógł: 6 Dołączył: 3.06.2007 Skąd: Kraków Ostrzeżenie: (0%) |
Dawno nie pisałem na forum dlatego pozdrawiam i witam wszystkich. Sporo siedziałem nad tym tematem i chciałbym pokazać swój sposób i prośić o ewentualny komentarz:
1. Tabela bazy sql "languages" zawiera pola: ID | name | short . Można ona pomiescić dowolną liczbę języków. 2. Przy starcie strony wybierany jest język o ID=1 który jest językiem głównym. Jego parametry zapisane są w sesji: $_SESSION["language"]="polish" $_SESSION["language_id"] = 1 $_SESSION["language_short"] = "pl". Teraz możemy dla całego serwisu wykożystywać te zmienne. Czasem przydają się wszystkie 3. 3. Kliknięcie na flagę języka zmajdującej się gdzieś na witrynie powodujemy zmianę tych 3 zmiennych. 4. Ładowane są odpowiednie pliki które zawierają definicje sztywne np: define( "_COM_NEWSLETTER_TITLE", "Newsletter" ); Zeby wszystko działało gładko każdy komponent ma swój plik z tłumaczeniem np "russian_newsletter.php". Każdy plik zawiera w nazwie język tak żeby przypadkiem sobie nie nadpisać przy wysyłaniu na serwer róznych plików językowych. 5. Każda tabela z tekstami wprowadzanymi do bazy zawiera pole "language" identyfikujący język. Nie tworzę osobnych tabel dla innych języków, dzięki temu przy dodaniu nowego języka nie muszę tworzyc nowych tabel dla każdego komponentu. ================== 6. Zauważyłem, że taki system pozwala na dużo ciekawych rozwiązań np: --- Można używać języka o ID=1 jako języka głównego a resztę jako reference. Wtedy przy odpowiedniej konfiguracji serwisu jeśli jakieś tłumaczenie nie istnieje łąduje się język główny i informacja, że wyświetlony został język natywny. --- Można wysłać do tłumacza cały folder lub plik z tłumaczeniami sztywnymi. --- Zmienną $_SESSION["language_short"] dobrze wykożystuje się do obrazków. Serwis może dla róznych języków załadować np "logo_pl.jpg" lub "logo_en.jpg" -------------------- http://www.berry.nazwa.pl/edico/public_html/index.php ----> under construction
|
|
|
27.12.2007, 11:18:32
Post
#64
|
|
Grupa: Zarejestrowani Postów: 136 Pomógł: 22 Dołączył: 19.09.2007 Skąd: Sosnowiec Ostrzeżenie: (0%) |
A ja się zastanawiam nad sensownością innego rozwiązania wielojęzykowości. Generalnie jeśli chodzi o treści statyczne (czy to formularze, czy proste zwroty na stronach wbudowane w szablon), to rozwiązanie na poziomie plików (sposób dowolny) wydaje się najsensowniejsze. Jeśli jednak chodzi o wielojęzykowość treści podlegających ciągłym zmianom takich jak na przykład artykuły, wiadomości i tym podobne sprawy, rozwiązanie praktycznie musi leżeć po stronie bazy danych.
Myślałem jednak nad rozwiązaniem tego w następujący sposób (to tylko czyste spekulacje, bo nie próbowałem tego wprowadzać w życie). Tabela odpowiadająca za artykuły (w sensie produkty, bo przykładem będzie wielojęzykowość na potrzeby e-commerce) przechowywane w bazie wg. pewnego bliżej nieokreślonego, przykładowego schematu (typy pól nieistotne): Tabela: products Kod Id produktu Cena produktu Kategoria produktu Data dodania Data wygaśnięcia Id promocji Stan magazynowy Tabela: products_lang Kod Id produktu Id/Skrót języka Nazwa produktu Szczegóły produktu Czyli rozbicie samych produktów na dwie osobne tabele bazy, a samo pobieranie danych za pomocą funkcji/procedur czy widoków. Z jednej strony to trochę "brudzenie" rozbiciem na tabele, z drugiej strony nie powielamy danych. Jak wszystko: posiada zalety jak i wady. To czy obecny język przechowujemy w zmiennej sesyjnej, czy też jako wartość bazy danych dla poszczególnych użytkowników zostawia się woli piszącego system i nie jest to rzecz istotna, dlatego nie roztrząsam tego problemu. Ten post edytował Nattfarinn 27.12.2007, 11:19:30 -------------------- Code should run as fast as necessary, but no faster; something important is always traded away to increase speed.
-- R. Pattis |
|
|
4.02.2008, 21:53:48
Post
#65
|
|
Grupa: Zarejestrowani Postów: 945 Pomógł: 7 Dołączył: 15.03.2005 Skąd: katowice Ostrzeżenie: (0%) |
ja stosuję metodę zapisu do bazy każdy element ma swój prefix językowy na tej podstawię identyfikuję wszystko.
|
|
|
1.03.2008, 12:07:43
Post
#66
|
|
Grupa: Przyjaciele php.pl Postów: 384 Pomógł: 6 Dołączył: 11.09.2004 Skąd: Grodzisk Mazowiecki Ostrzeżenie: (0%) |
W Doctrine jest plugin do i18n. Wielojęzykowość staje się wtedy bardzo przyjemna.
http://www.phpdoctrine.org/documentation/m...ation-with-i18n -------------------- |
|
|
4.03.2008, 10:43:03
Post
#67
|
|
Grupa: Zarejestrowani Postów: 569 Pomógł: 0 Dołączył: 17.08.2003 Skąd: Dąbrowa Górnicza Ostrzeżenie: (0%) |
a jak w tym doctrine wyglada to tłumacznie ? Osobne tabele ? Bo przy jednej jezykowosci jakos to widze przy powiedzmy 6-10 prawdopodobnie zaczely by sie schody z iloscia rekordow, a nie mowiac juz o wiecej ilosci rekordow powiedzmy z wiadomosciami, opisami, cechami przedmiotow/produktow.
No i czy to by uwzglednialo powtarzajace sie frazy. Pytam tak bo szukam jakiegos dobrego rozwiazania wielojezykowego i jedynie na chwile obecna gettext jakos dziala, ale to tez ma swoje ograniczenia. -------------------- Warsztat: Linux: PHP, MySQL, Apache, NetBeans, C++, Qt-Creator
Użytkownik, słowo którego specjaliści IT używają, gdy chcą powiedzieć idiota Zarządzaj swoim budżetem domowym |
|
|
14.03.2008, 13:08:25
Post
#68
|
|
Grupa: Przyjaciele php.pl Postów: 384 Pomógł: 6 Dołączył: 11.09.2004 Skąd: Grodzisk Mazowiecki Ostrzeżenie: (0%) |
Przykład z dokumentacji doctrine:
news: id | content news_translation: id | title | lang W tym przypadku dla newsów będą tytuły w różnych językach. A używając doctrine wyciąga sie je tak:
Możesz jednak zmodyfikować ten plugin aby działał on inaczej. Sam plugin nie jest jakoś specjalnie skomplikowany, jak i również pisanie pluginów dla Doctrine jest proste. Tak w ogóle to polecam Doctrine. To naprawdę bardzo dobry ORM. -------------------- |
|
|
22.05.2008, 09:10:58
Post
#69
|
|
Grupa: Zarejestrowani Postów: 4 Pomógł: 0 Dołączył: 11.05.2007 Ostrzeżenie: (0%) |
|
|
|
22.05.2008, 12:00:40
Post
#70
|
|
Grupa: Zarejestrowani Postów: 246 Pomógł: 31 Dołączył: 13.11.2006 Skąd: się znamy? Ostrzeżenie: (0%) |
(sorry za odkop) Nie można po prostu użyć prefixów w bazie danych? np. tabela pl.news en.news w PHP:
Oczywiście, że możesz ale to mało elastyczne. Było to już wałkowane we wcześniejszych postach (nie przeczytałeś?). Wiele danych będzie się powtarzać a dodanie kolejnej wersji językowej wymaga dodania tabeli. Cytat news id | author_id | created_at | ... news.translation ... | news_id | lang | title | content ... Nie sensowniej? -------------------- Goldenline: Łukasz Rodziewicz
|
|
|
23.05.2008, 17:52:07
Post
#71
|
|
Grupa: Zarejestrowani Postów: 1 657 Pomógł: 125 Dołączył: 29.04.2006 Ostrzeżenie: (0%) |
Mam jeden prosty i sprawdzony sposób.
I tyle. Funkcja __ wyszukuje w specjalnej tablicy dany string i do niego przyporządkowuje odpowiednie tłumaczenie. Tablice wyglądają np. tak: plik langs/en/cnt_test.php : $langArray['modules/controllers/test.php']['Witaj Świecie!'] = 'Hello World'; Zamiast ['modules/controllers/test.php'] może być [''] - wtedy dane tłumaczenie będzie obejmowało wszystkie pliki. -------------------- |
|
|
23.05.2008, 19:10:41
Post
#72
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
@radex_p
Co innego tłumaczenie statycznych rzeczy, co innego dynamicznie dodawanych. -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
23.05.2008, 19:52:53
Post
#73
|
|
Grupa: Zarejestrowani Postów: 1 657 Pomógł: 125 Dołączył: 29.04.2006 Ostrzeżenie: (0%) |
Co masz na myśli? Te tablice z tłumaczeniami są (o ile dobrze zrozumiałem) statyczne.
EDIT: Chyba już wiem, co miałeś na myśli. Napisałem "przyporządkowuje". __() nie dodaje tłumaczenia, tylko zwraca tłumaczenie stringa zawartego w argumencie. Ten post edytował radex_p 23.05.2008, 19:57:25 -------------------- |
|
|
23.05.2008, 21:01:49
Post
#74
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
@radex_p - myślę, że chodziło o np. artykuł dodawany do serwisu. Który tłumaczysz na polski, angielski czy niderlandzki.
|
|
|
24.05.2008, 08:40:48
Post
#75
|
|
Grupa: Zarejestrowani Postów: 1 657 Pomógł: 125 Dołączył: 29.04.2006 Ostrzeżenie: (0%) |
aaaaa..... Teraz już rozumiem
-------------------- |
|
|
24.05.2008, 10:25:24
Post
#76
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
Dokładnie, bo można rozgraniczyć na dwa rodzaje, jeden to to co jest właściwie raz tworzone, czyli komunikaty, teksty np. "Dodaj komentarz" itp. co jest przez nas robione, drugie to są rzeczy dodawane dynamicznie, czyli artykuły, wiadomości czy co tam w aplikacji zaoferujemy. Te drugie są w bazie danych więc, oczywiste jest że wszystkie wersje językowe tam muszą być.
Co do pierwszych, no to już jak widać różne opinie, ja do opisu statusów wykorzystuję bazę danych, bo i tak muszą być w bazie przez FK. Co do tekstów, to można zrobić tak jak już było nieraz podane, przez funkcję, ale tak na prawdę skąd ona bierze te dane, to już inna sprawa, ważne jest że w kodzie widzimy tekst jaki ma się pojawić a nie jakiś jego znacznik. Można by dyskutować, a co jak nie będzie działać baza danych? Ale tak na prawdę to jak nie działa, to już cała strona też, więc tylko komunikat o niemożliwości połączenia z bazą musi być w pliku zapisany. -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
29.05.2008, 11:32:28
Post
#77
|
|
Grupa: Zarejestrowani Postów: 9 Pomógł: 0 Dołączył: 10.12.2007 Ostrzeżenie: (0%) |
Obecnie korzystam z Symfony i podoba mi sie jak to tam jest rozwiązane.
Przypomne: Teksty statyczne - XML i funkcja __('tekst') Teksty dynamiczne - dwie tabele, np. products (id, symbol, item_number) i products_i18n(id,lang,name,description) Jedyny minus Symfony to jeżeli brak tłumaczenia dla danego obiektu (np. nazwy produktu), wyświetlany jest pusty string, a w mojej aplikacji chciałbym żeby jeśli np. brak tłumaczenia polskiego, było wyświetlane tłumaczenie angielskie domyślnie. Oczywiście da się tak zrobić modyfikując propelowy generator, no ale znów generuje to dodatkowe zapytania do bazy. Swojego czasu napisałem własny ORM który wykorzystał rozwiązanie jakiego tu jeszcze nikt nie zaproponował Miałem tabele w bazie danych: strings id (int) lang content (varchar255) texts id (int) lang content(text) gdzie id i lang były kluczem głównym. Jeżeli w którejkolwiek innej tabeli miał być content zależny od języka, oznaczałem to tak: products id symbol string_name (int) text_description (int) ORM w momencie pobierania obiektu z bazy danych, przed przygotowanie query, jeżeli napotkał pola z prefixem "string_" bądź "text_" robił joina z odpowiednia tabela strings bądż texts. Podobnie przy zapisie i uaktualnieniu danych. Co sądzicie o takim rozwiązaniu? Jego zaleta to taka, że nie muszę projektować dodatkowych tabel _i18n, wystarczy że wszystkie pola zależne od języka będę oznaczał jako string_ bądż text_. Wada to oczywiście dodatkowy join w każdym zapytaniu (ale w symfony jest to samo), koniecznosc napisania wlasnego orm badz zmodyfikowania istniejacego, no i tak jak wcześniej napisałem, problem gdy chcemy korzystać z degradacji języka (czyli nie ma polskiego to angielski, nie ma angielskiego to niemiecki itp) |
|
|
29.05.2008, 14:18:48
Post
#78
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
@joohn
Wada, to że wszystkie teksty są wrzucone do jednego worka, czyli tak na prawdę nie wiemy co to jest, tylko tyle że jakieś teksty. -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
29.05.2008, 20:01:46
Post
#79
|
|
Grupa: Zarejestrowani Postów: 592 Pomógł: 62 Dołączył: 3.08.2006 Ostrzeżenie: (0%) |
Witam!
Podsumowując, moim zdaniem optymalnym rozwiązaniem: dla elementów stałych jest utworzenie przykładowej klasy Language:
dla elementów dynamicznych (każdy język -> inna treść):
by Sedziwoj: tabela z językami
Oczywiście, że istnieją inne rozwiązania jak np. tabele pl_news, en_news, lecz te sposoby, które przedstawiłem wydają mi się najbardziej elastyczne i uniwersalne. Pozdrawiam! Ten post edytował rzymek01 30.05.2008, 13:45:44 -------------------- :]
|
|
|
30.05.2008, 08:44:00
Post
#80
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
@rzymek01
Jak masz kolumnę lang, to niech to będzie integer, po co męczyć bazę stringiem, do tego najlepiej lang_id, i tabela gdzie jest id|short_name|name czyli skrócona nazwa języka np. PL i pełna Polski. -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
Wersja Lo-Fi | Aktualny czas: 22.06.2024 - 23:06 |