Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Zasady pisania na forum Pro

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.

9 Stron V  < 1 2 3 4 5 > »   
Reply to this topicStart new topic
> Wielojęzykowość, Czekam na Wasze propozycje
pawkow
post 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ę ?
Go to the top of the page
+Quote Post
Zeman
post 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
  1. <?php
  2. echo('{*pl:To jest komputer**eng:This is computer*}');
  3. ?>

i wypluwa kod php z zamienionym powyższym na mniej więcej
  1. <?php
  2. echo(''.lang_const_1.'');
  3. ?>
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
Go to the top of the page
+Quote Post
Diabl0
post 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
Go to the top of the page
+Quote Post
Sedziwoj
post 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.
Go to the top of the page
+Quote Post
Athlan
post 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:

  1. <?php
  2.  
  3. final class fr_Vlang extends VlangPattern
  4. {
  5. public $foo = 'C’est le foo.';
  6.  
  7. public $change_id = 'Polski';
  8. public $change_sr = 'FR';
  9.  
  10. public $entry_add_true = 'L’entrée a été ajoutée avec succes! Afficher?';
  11. public $entry_add_false = 'Erreur de base de données, entrée non ajoutée!';
  12. public $entry_add_false_text = 'Copiez ici le code a ajouter!';
  13. public $entry_add_false_token = 'L’identifiant d’autorisation est erroné!';
  14. public $entry_link = 'Voici le lien vers votre entrée:';
  15. public $entry_connection_lost = 'Impossible d’accéder au serveur, réessayez.';
  16.  
  17. // itd itd itd...
  18.  
  19. }
  20. ?>


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 smile.gif

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.
Go to the top of the page
+Quote Post
Sedziwoj
post 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%)
-----


Cytat(Athlan @ 4.04.2007, 08:05:59 ) *
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 blinksmiley.gif


--------------------
Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami.
Go to the top of the page
+Quote Post
Zeman
post 4.04.2007, 11:11:42
Post #47





Grupa: Zarejestrowani
Postów: 70
Pomógł: 0
Dołączył: 29.03.2007

Ostrzeżenie: (0%)
-----


Cytat(Diabl0 @ 4.04.2007, 02:17:23 ) *
...
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 winksmiley.jpg

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
Go to the top of the page
+Quote Post
Kayne
post 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óż winksmiley.jpg

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:

  1. <?php
  2. $test = mysql_query('SELECT * FROM articles WHERE lang='en');
  3. ?>


Ten post edytował Kayne 4.04.2007, 14:34:34


--------------------
Chcesz szybko i łatwo wygrać 100 zł?
Go to the top of the page
+Quote Post
bela
post 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


--------------------
Go to the top of the page
+Quote Post
Kayne
post 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 smile.gif


--------------------
Chcesz szybko i łatwo wygrać 100 zł?
Go to the top of the page
+Quote Post
empathon
post 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 wub.gif


--------------------
Goldenline: Łukasz Rodziewicz
Go to the top of the page
+Quote Post
bela
post 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.


--------------------
Go to the top of the page
+Quote Post
cicik
post 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
Go to the top of the page
+Quote Post
faster
post 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%)
-----


Cytat(bela @ 4.04.2007, 17:52:29 ) *
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 smile.gif. 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 smile.gif and so on ...

pozdro

... tak zrobię a potem podzielę się uwagami z pola boju

Ten post edytował faster 30.04.2007, 00:20:26
Go to the top of the page
+Quote Post
Siner
post 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?


--------------------
Go to the top of the page
+Quote Post
Nitryt14
post 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
Go to the top of the page
+Quote Post
kubarek
post 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:
  1. <?php
  2. class language
  3. {
  4.  
  5.  function __construct($language='pl'){
  6. $this->language=$language;
  7. $this->get_data();
  8.  }
  9.  
  10.  function __get($id){
  11. return $this->data[$id];
  12.  }
  13.  
  14.  function get_data(){
  15. /* funkcja jakoś pobierze dane językowe, np z bazy danych mysql */
  16. /* mogą być to dane zapisane już jako tablica w pliku php */
  17. include 'plik_z_jezykiem_'.$this->language.'.php';
  18. /* etc. */
  19. $this->data=...
  20.  }
  21.  
  22. }
  23.  
  24. $l='pl';
  25.  
  26. $lang=new language($l);
  27.  
  28. echo $lang->10;
  29. echo $lang->1337;
  30. ?>


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 ;)
Go to the top of the page
+Quote Post
eai
post 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:
  1. <?php
  2.  
  3. $glang[] = 'polish';
  4. $glang[] = 'english';
  5. $glang[] = 'spanish';
  6.  
  7. ?>


Folder __language: Zawiera pod foldery z plikami językowymi oraz z interfejsem

interface.php:
  1. <?php
  2.  
  3. $interface['val1'] = null;
  4. $interface['val2'] = null;
  5. $interface['val3'] = null;
  6. //... itd są to indexy które muszą występować w każdym pliku językowym w tym folde
    rze
  7. ?>

lang.polish.php:
  1. <?php
  2.  
  3. $lang['val1'] = 'czesc';
  4. $lang['val2'] = 'czas';
  5. $lang['val3'] = 'zegnaj';
  6. ?>


lang.english.php:
  1. <?php
  2.  
  3. $lang['val1'] = 'hello';
  4. $lang['val2'] = 'time';
  5. $lang['val3'] = 'goodbye';
  6. ?>


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.
Go to the top of the page
+Quote Post
Sedziwoj
post 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.
Go to the top of the page
+Quote Post
siemakuba
post 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?
  • Łatwiej dodać język, zakładając, że system wie, które z tabel są "wrażliwe na język" - wystarczy zrobić skrypt kopiujący strukturę tych tabel i zmieniający ich nazwę
  • Do obsługi danych używam klas modeli opartych na wzorcu ActiveRecord. Aby pobrać dane z tabeli articles o id=10 robię tak:
    1. <?php
    2. $this->ArticlesModel->FinById(10);
    3. ?>
    Przy nazwach tabel z dodanym oznaczeniem języka, konieczne by było posiadanie modelu dla każdej tabeli, lub co wydaje mi się prostsze i oczywiste, zbudowanie jakiegoś Factory dla tych modeli - w momencie, kiedy tworzę model, sprawdzam czy jest to tabela wrażliwa językowo i wtedy uruchamiam fabrykę. Dzięki temu, zawsze do danych o artykułach dostanę się przez $this->ArticlesModel (nie potrzebuję mieć, ArticlesPl_Model czy ArticlesDe_Model). Również przy dodaniu języka nie interesuje mnie budowa nowego modelu - factory zrobi to za mnie.
  • Może być to również słuszne z punktu widzenia danych na stronie. Przy rozwiązaniu takim: tabela articles (title_pl, title_en, title_de,...) przy wyświetlaniu danych pobierałbym przy wybranym angielskim title_en. A co jeżeli te informacje nie zostały uzupełnione? Mam puste dane? Czy może pokazuję po polsku? Przy wielu tabelach dane te są niezależne od siebie, i taki problem się nie rodzi, a przynajmniej można sobie darować dodatkowe warunki sprawdzające czy mam odpowiednie dane w takim języku (bo rekord dla tych danych zostanie utworzony jeżeli zostaną one dodane w jakimkolwiek języku)

Co o tym myślicie? Mi wydaje się całkiem słuszne, choć na chwilę obecną to tylko teoria ;)

pozdr.
Go to the top of the page
+Quote Post

9 Stron V  < 1 2 3 4 5 > » 
Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 19.03.2024 - 03:00