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 |
21.03.2007, 21:16:19
Post
#41
|
|
Grupa: Zarejestrowani Postów: 76 Pomógł: 7 Dołączył: 30.09.2006 Ostrzeżenie: (0%) |
musiałbyś poprawić tylko jeden plik, czy się mylę ?
|
|
|
3.04.2007, 21:34:22
Post
#42
|
|
Grupa: Zarejestrowani Postów: 70 Pomógł: 0 Dołączył: 29.03.2007 Ostrzeżenie: (0%) |
Korzystam z autorskiego edytora i 2 pluginów multijezykowych:
1. pierwszy pozwala mi pisać w kodzie php coś takiego
i wypluwa kod php z zamienionym powyższym na mniej więcej oraz dodatkowy plik ze stałymi 2. drugi wyciąga wszystkie zastosowania powyższej postaci z wszystkich plików projektu i zestawia je w siatce Suma sumarum w efekcie końcowym można powiedzieć że stosuję metodę podstawiania stałych i tworzenia plików postaci .../pl/index.php gdzie są stałe z tekstami. Pozwiodronka, Zeman. -------------------- www.web2biz.pl | trochę o web-usability
|
|
|
4.04.2007, 01:17:23
Post
#43
|
|
Grupa: Zarejestrowani Postów: 24 Pomógł: 1 Dołączył: 25.03.2006 Ostrzeżenie: (0%) |
Widzę że prawie każdy skupił się tylko na jednej (IMHO prostszej) stronie medalu jakim są teksty stałe. Tutaj w zasadzie pomysły są 2/3 (tablice, pliki ini i pokrewne własne formaty i ewentualnie i18n) różniące się tylko sposobem implementacji. Mnie natomiast interesuje ta ciekawsza strona medalu jaką jest:
Jak rozwiązujecie kwestie wielu języków w bazach danych. Jak do tego podchodzicie robiąc projekt z założenia 2-językowy (np. pl i en) oraz jak to rozwiązujecie mając w planie pełną wielojęzykowość bez z góry określonej liczby języków. Interesuje mnie nie tylko jak kształtujecie samą bazę ale także typowe odwołania do niej. W przypadku projektów 2-językowych korzystam głównie z typowej konstrukcji wielokolumnowej: id | date | title_pl | title_en | content_pl | content_en dorzucając do niej ewentualnie pole boolean valid_{$lang} określające czy dany język występuje w danym rekordzie. Użycie w kodzie dość banalne: $SQL = 'SELECT title_' . $_USER['lang'] . ', content_'' . $_USER['lang'] itd Natomiast w przypadku projektów wielojęzykowych mam zawsze dylemat jak konstruować bazę danych. -------------------- Blog
|
|
|
4.04.2007, 01:31:24
Post
#44
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
Czy mi się wydaje czy to jest jeden 'artykuł' -> wiele wersji? Bo takie określenie podsuwa od razu sposób rozwiązania.
czyli tabele wiążącą 'artykuł' z treścią, coś w stylu: artykul_id|tresc_id|jezyk_id (czy coś podobnego, bo język można przecież określić na zbiorze, ale z drugiej strony może być w tabeli języków nazwa skrótowa jak i cała, też ułatwi sprawdzenie jakie języki obsługuje) Ale to tak na z marszu piszę, do tego mam nikłe doświadczenie, więc lepiej niech ktoś lepszy w tych sprawach skomentuje... -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
4.04.2007, 07:05:59
Post
#45
|
|
Grupa: Developerzy Postów: 823 Pomógł: 12 Dołączył: 18.12.2005 Ostrzeżenie: (0%) |
Moim zdaniem baza danych w zupełności odpada, bez sensu, przy dużych iloścach informacji czas działania aplikacji zwrasta, a nie o to chodzi. U mnie wszystkie pliki językowe siedzą w plikach:
/Application/Languages/Polish/Polish.Language.php - domyślny plik języka polskiego /Application/Languages/Polish/Subgrupa_Polish.Language.php - inny plik języka polskiego, przykład: /Application/Languages/Polish/Register_Polish.Language.php Budowa takiego pliku jest następująca:
Dodatkowo automatycznie wybierany jest domyślny język użytkownika. Aby wymusić priorytet języka, w jego folderze tworzymy plik Język.tmp z wartością w środku od 0.1 - 1, przykład: /Application/Languages/Polish/Polish.tmp Klasy: http://framework.vgroup.pl/expose-409ea1a4...af9923731ec.htm http://framework.vgroup.pl/expose-d41766b6...fb6deba59c0.htm Przykład działania wielojęzykowości możecie zobaczeć na www.cpaste.com... działa pięknie Pozdrawiam, Athlan -------------------- Portfolio: Vgroup.pl | athlan.pl | Test.php.pl - sprawdź się z wiedzy o PHP i ułóż własne pytania!
Pomogłem? Kliknij pod postem. |
|
|
4.04.2007, 10:02:09
Post
#46
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
Moim zdaniem baza danych w zupełności odpada, bez sensu, przy dużych iloścach informacji czas działania aplikacji zwrasta Czyli Twoim zdaniem przy dużych ilościach informacji trzeba używać plików nie baz danych -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
4.04.2007, 11:11:42
Post
#47
|
|
Grupa: Zarejestrowani Postów: 70 Pomógł: 0 Dołączył: 29.03.2007 Ostrzeżenie: (0%) |
... id | date | title_pl | title_en | content_pl | content_en ... Użycie w kodzie dość banalne: $SQL = 'SELECT title_' . $_USER['lang'] . ', content_'' . $_USER['lang'] itd ... Natomiast w przypadku projektów wielojęzykowych mam zawsze dylemat jak konstruować bazę danych. Takie podejście może być trochę męczące przy pisaniu zapytań. Ponadto nie bardzo daje możliwość utworzenia różnych danych dla różnych języków, mam na myśli przykładowo, że sklep oferuje w wersji polskiej pewną ilość produktów, w wersji angielskiej może niektórych produktów nie chcieć proponować. Jeszcze bardziej gdy wyobrazimy sobie produkty w sklepie i komentarze klientów, jakby nie patrzeć, nie możemy kazać komentować we wszystkich językach naraz Osobiście preferuję nazwy tabel products_pl, products_eng, products_de, .... i oczywiście 'SELECT id, title, .. FROM products_'.$lang.' ...' Jeśli klient jednak przewiduje że każdy rekord będzie miał odzwierciedlenia we wszystkich językach, to niby można się pokusić o sposób id | date | title_pl | title_en | content_pl | content_en, choć osobiście pewnie bym zastosował coś innego, co to jeszcze nie wiem, bo nie miałem przypadku żeby każdy rekord miał być we wszystkich językach. Można niby tabelę "mapującą" products: products_pl_id, products_en_id, ... -------------------- www.web2biz.pl | trochę o web-usability
|
|
|
4.04.2007, 14:29:46
Post
#48
|
|
Grupa: Zarejestrowani Postów: 82 Pomógł: 0 Dołączył: 30.04.2006 Skąd: Kalisz Ostrzeżenie: (0%) |
Hm... Jest trochę prostsze rozwiązanie, z którego ja korzystam. Może i jest przez to więcej rekordów w bazie danych... no ale cóż
Ogólnie koncepcja jest prosta. Mamy tabelę articles: id | date | title | body | author |lang Pole lang jest polem CHAR (2) w którym mamy podane np.: pl, en, fr... Czyli pobranie artykułu po angielsku to po prostu:
Ten post edytował Kayne 4.04.2007, 14:34:34 -------------------- Chcesz szybko i łatwo wygrać 100 zł?
|
|
|
4.04.2007, 16:52:29
Post
#49
|
|
Administrator PHPedia.pl Grupa: Developerzy Postów: 1 102 Pomógł: 2 Dołączył: 14.09.2003 Ostrzeżenie: (0%) |
rozwiazanie powyzej jest fajne, ale ma jedna wade: dane w bazie sie powtarzaja
ja uzywam symfony i rozwiazania z tamtego frameworka, czyli mamy dwie tabele w jednej sa dane, ktore sie nie zmieniaja np id uzytkownika, data utworzenia a w drugiej teksty powiazane za pomoca klucza obcego i dodatkowo pole z jezykiem -------------------- |
|
|
6.04.2007, 11:48:54
Post
#50
|
|
Grupa: Zarejestrowani Postów: 82 Pomógł: 0 Dołączył: 30.04.2006 Skąd: Kalisz Ostrzeżenie: (0%) |
No, powtarzają się, ale jest to bardzo łatwe do zaimplementowania. Odpowiednia budowa tabel w bazie danych a będzie śmigać aż miło
-------------------- Chcesz szybko i łatwo wygrać 100 zł?
|
|
|
9.04.2007, 16:01:43
Post
#51
|
|
Grupa: Zarejestrowani Postów: 246 Pomógł: 31 Dołączył: 13.11.2006 Skąd: się znamy? Ostrzeżenie: (0%) |
Ja podobnie jak ~bela używam symfony i uważam tamto rozwiązanie za optymalne. Zarówno pod względem przechowywania elementów interface i treści w bazie danych. Polecam zapoznanie się z tym jak jest to tam rozwiązane
-------------------- Goldenline: Łukasz Rodziewicz
|
|
|
9.04.2007, 19:52:04
Post
#52
|
|
Administrator PHPedia.pl Grupa: Developerzy Postów: 1 102 Pomógł: 2 Dołączył: 14.09.2003 Ostrzeżenie: (0%) |
jezeli ktos sie zdecyduje na symfony, to radze pobierac przez metode doSelectWithI18n, bo samo doSelect nie pobiera danych z jezykow i za kazdym razem wali selecta.
-------------------- |
|
|
12.04.2007, 21:45:21
Post
#53
|
|
Grupa: Zarejestrowani Postów: 219 Pomógł: 5 Dołączył: 18.07.2006 Skąd: Piekary Śląskie Ostrzeżenie: (0%) |
Od jakiegoś czasu zastanawiam się na wielojęzykowością w moich projektach i patrząc na potrzeby moich klientów widzę cztery mechanizmy opisujące ich oczekiwania:
1. Klient chce mieć TYLKO z góry określoną liczbę języków. W takich wypadkach robię po prostu jak kolega wyżej zaproponował, czyli kolumny w tabeli: tytul_pl, tytul_en etc. 2. Klient chce mieć stronę w kilku językach ale one generalnie są niezależne (różne działy etc.). Wtedy po prostu robię kilka stron, którymi da się administrować z jednego panelu. 3. Klient chce mieć jedną stronę w kilku językach, każdy artykuł w różnych wersjach językowych. Internauta przełącza się pomiędzy wersjami za pomocą linków (np. chorągiewek z flagami). W bazie jest to zapisywane jako relacja n do n pomiędzy artykułami i językami gdzie w relacji łączącej jest zapisany tytuł i treść artykułu w odpowiednim języku. 4. Klient chce mieć stronę generalnie w jednym języku (menu etc.) ale poszczególne artykuły w kilku wersjach wyświetlanych na jednej stronie. Baza jest podobna do tej z pkt. 3. Przypadek 1. jest szczególną formą jednego z pozostałych. -------------------- CMS dla Twojej firmy
Wojciech Małota |
|
|
30.04.2007, 00:15:28
Post
#54
|
|
Grupa: Zarejestrowani Postów: 49 Pomógł: 0 Dołączył: 9.09.2002 Skąd: Pszczyna Ostrzeżenie: (0%) |
rozwiazanie powyzej jest fajne, ale ma jedna wade: dane w bazie sie powtarzaja ja uzywam symfony i rozwiazania z tamtego frameworka, czyli mamy dwie tabele w jednej sa dane, ktore sie nie zmieniaja np id uzytkownika, data utworzenia a w drugiej teksty powiazane za pomoca klucza obcego i dodatkowo pole z jezykiem Moim zdaniem, rozwiązanie zaproponowane prze Kayne jest bardziej wydajne. Wzrost ilości rekordów nie jest raczej problemem podczas, gdy odwoływanie się do dwóch tabel w celu uzyskania danych jest bardziej obciążające. Rozważając ten problem myślałem początkowo o zastosowaniu właśnie tablic z tłumaczeniami (trochę podobne rozwiązanie jakie opisał bela) czyli mamy tablicę z danymi np. produkty czy też osoby a mamy również w systemie tablicę tlumaczenia (id,tabela,pole,jezyk,dane) i tam zapisujemy "tłumaczenia" wartości domyślnych. Jak słusznie można zauważyć rozwiązanie pozostawia wiele do życzenia . Kayne natomiast otworzył mi oczy na proste i moim zdaniem bardzo wydajne i uniwersalne rozwiązanie (zmieniasz strukturę danych dodając kolejne pola nie martwisz się o języki - w bazie dodają się same). Zastanawiałem się jeszcze nad problemem podczas obsługi na formularz i wieloma językami. Co sądzicie o takim mechanizmie: normalnie funkcjonuje domyślny formularz tylko w jednym języku, gdy chcemy dodać tłumaczenie klikamy na przycisk z wyborem języka i pojawia nam się okienko z formularzem z polami w danym języku and so on ... pozdro ... tak zrobię a potem podzielę się uwagami z pola boju Ten post edytował faster 30.04.2007, 00:20:26 |
|
|
13.05.2007, 16:19:31
Post
#55
|
|
Grupa: Zarejestrowani Postów: 159 Pomógł: 6 Dołączył: 2.01.2004 Ostrzeżenie: (0%) |
Ostatnio zastanawiam się nad wyglądem linków wielojęzykowej strony.
Z jednej strony ciekawym rozwiązaniem było by budowanie strony na zasadzie: "example.com/kontakt/" - dla polskiej wersji językowej, a "example.com/contact/" - w przypadku anglojezycznej wersji. Ale co w przypadku gdy np po niemiecku kontakt pisze się tak samo jak po polsku, można zawsze wczytywać język przeglądarki w takim wypadku i zapisywać go do sesji, ale czy to nie będzie "przyrost formy nad treścią"? Dodatkowa sprawa to zapisywanie jak mają wyglądać linki w danym języku, pobieranie z bazy danych bądź pliku zawsze trochę zmniejszy trochę szybkość No i jak na takie rzeczy reagują wyszukiwarki, bo zmniejsza to chyba to skuteczność trafności wyników. Macie jakieś inne ciekawe sposoby na budowanie odnośników na stronach wielojęzykowych? -------------------- |
|
|
13.05.2007, 17:23:59
Post
#56
|
|
Grupa: Zarejestrowani Postów: 76 Pomógł: 0 Dołączył: 17.02.2004 Skąd: Gdańsk Ostrzeżenie: (0%) |
Mam podobny problem jezykowy przy tworzeniu strony moich rodzicow.
Maja biuro projektowe, a na stronce chcą miec dane kontaktowe oraz opisy wraz ze zdjąciami budynków przez nich zaprojektowanych. Wymyśliłem nastepujace rozwiazanie: - dane stale takie jak dane kontaktowe, wszystkie podpisy (menu, strona główna etc.) przechowywał bym w plikach lang_xx.php - a dane zmienne (opisy budynków, zdjęć etc.) dodawał bym do bazy danych przy czym każdy język... i tu sie pojawia problem czy lepiej żeby miał osobną baze (np. sim_pl etc.) czy wystarczy osobna tabela (np. opisy_pl etc.) chyba ze by było jakieś jeszcze lepsze rozwiązanie. -------------------- Człowiek boi się tego czego nierozumie
--- Blog początkującego programisty |
|
|
13.05.2007, 20:02:42
Post
#57
|
|
Grupa: Zarejestrowani Postów: 43 Pomógł: 0 Dołączył: 19.02.2007 Ostrzeżenie: (0%) |
moja idea:
i w tym przypadku ( gdy zmienna $l zawiera 'pl' ), instrukcja $lang->10 może wyświetlić np. 'Witaj świecie', a po zmianie $l na en może pokazać 'Hello world', podobnie jak z np. $lang->1337 chodzi, o to, że każdy tekst ma przypisany swój unikalny id, ergo dodanie/usuwanie/modyfikowanie danych językowych nie będzie skomplikowane to jest w przypadku jakichś stałych danych, np. komunikatów z błędami czy czegoś podobnego; nie myślałem na razie o tym, jak zrobić żeby działało dla artykułów w wielu językach -------------------- // ...
Co nieco o mnie ;) |
|
|
14.05.2007, 09:41:24
Post
#58
|
|
Grupa: Zarejestrowani Postów: 367 Pomógł: 10 Dołączył: 20.05.2005 Ostrzeżenie: (0%) |
Mój sposób wygląda tak:
Plik Global_Lang.php:
Folder __language: Zawiera pod foldery z plikami językowymi oraz z interfejsem interface.php:
lang.polish.php:
lang.english.php:
Klasa Language zawiera funkcje laczaca wszystkie pliki w jedna statyczna tablice (tylko aktualnie wybranego jezyka), podczas mapowania folderow i laczenia plikow sprawdza czy sie zgadzaja indexy z plikiem interface.php jesli cos jest nie tak wywala ostrzeżenie lub error (Klasa Exceptions). Po zmapowaniu wszystkich plikow zapisujemy sobie zserializowana tablice do pliku compiled.lang.polish.php (aktualnie wybrany język). Dzieki temu nie musimy ponownie skanować folderów, poprostu dołączamy plik z tablicą. Sprawdza rowniez czy sa wszystkie pliki z jezykami (Global_lang.php) Umożliwia również tworzenie nowych języków z poziomu www, pobiera podfoldery z folderu __language wraz z plikiem interface.php, wyswietla wszystko w formularzu form w krokach jeden formularz to jeden podfolder. Do póki administrator nie uzupełni wszystkich kroków nowy język nie zostanie dodany do aplikacji, jeśli wszystko uzupełnił zapisujemy nowy język w pliku.php do każdego podfolderu. W ten sposób wykorzystuje to do stałych wartości które chce mieć w różnych językach, np wyświetlanie komunikatów o błędach, czy jakieś stałe nazwy w linkach typu Rejestracja,Register itd.. Inaczej trzeba podejść gdy chcemy mieć wielojęzyczne artykuły tutaj po stronie artykułów trzeba mieć odpowiednie funkcje które do tabeli dodadzą nam nowy język nie trzeba będzie tłumaczyć każdego artykułu podczas dodawania języka tak jak do tej pory, tylko wyświetlenie komórki z domyślnym językiem. Chociaż może to odbywać się też w klasie Language który wygeneruje nam polecenie SQL. Według mnie takie rozwiązanie daje możliwość swobodnego zarządzania językami. Jestem w trakcie pisania, jak dokończe pokaże jak to wyszło. |
|
|
14.05.2007, 09:51:22
Post
#59
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
A mnie tak ciągle zastanawia, dlaczego artykuły/newsy itp. idą z id języka do bazy danych, a już np. nazwy działów lecą do plików?
Przecież to są informacje które można modyfikować, jak jeszcze założymy że tych elementów nie można przez panel admina ruszać to można by było podciągnąć pod statyczne elementy, ale przy możliwości dodania języka? Ale może niech ktoś, kto ma jakieś pojęcie o tym wypowie, bo ja sobie tak gdybam i tylko jedna rzecz przychodzi mi do głowy, która może determinować wybór, aby za każdym razem nie pobierało danych z bazy. Tylko że baza ma służyć do przechowywania i sprawnej dystrybucji danych... -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
14.05.2007, 15:17:27
Post
#60
|
|
Grupa: Przyjaciele php.pl Postów: 1 112 Pomógł: 20 Dołączył: 10.04.2005 Ostrzeżenie: (0%) |
Pojawił się w tym wątku pomysł, aby trzymać dane zależnie od języków w odpowiednich tabelach, przykładowo:
Kod articles_pl articles_en articles_de Początkowo wydało mi się to niezbyt dobre rozwiązanie, ale po zastanowieniu, może to być całkiem słuszne. Dlaczego?
Co o tym myślicie? Mi wydaje się całkiem słuszne, choć na chwilę obecną to tylko teoria ;) pozdr. |
|
|
Wersja Lo-Fi | Aktualny czas: 27.09.2024 - 10:13 |