Struktura aplikacji wielojęzykowej Opcje

[tabbi]

Witam,

mam problem przy projektowaniu w jaki sposób powinna wyglądać prawidłowo zrobiona aplikacja wielojęzykowa. Do dyspozycji mamy nazwę dostępną w kilku domenach. Pytanie na czym się skupić i tak by było to przejrzyste oraz dobrze zrozumiane przez google.

Strona będzie zawierać:
podstawowe strony informacyjne typu kontakt, rejestracji itp.
panel użytkownika
publiczne podstrony profilów.

Mój sposób wygląda tak że wszystkie domeny będą przekierowywać w jedno miejsce i w zależności od domeny (pl,it,net) będą ładowały treść w danym języku. Tutaj może się jednak pojawić problem z sesjami gdyż dla dwóch domen będą tworzone dwie różne sesje ... ?

Patrząc np. facebooka, tutaj mamy raczej do czynienia z przekierowaniem np domenę główną .com z odpowiednią subdomeną. http://facebook.pl/badges/ -> http://pl-pl.facebook.com/badges/

Ktoś miał styczność z takim problemem architektonicznym ?

[Szymciosek]

Witam,
ja podczas tworzenia pewnej strony w 2 językach, opierałem się na plikach json z konkretnym językiem np. about_pl.json, on sobie tam zawierał potrzebne dane, które chciałem wyprowadzić na stronę.

Sam url wyglądał w sposób: www.superstrona.com/pl/about
czyli: www.superstrona.com/{lang}/{content}

Router stworzony tak żeby za pomocą tych 2 "zmiennych" lang i content pobierał odpowiednie pliki itd.

Teraz możesz zrobić, że domyślny język jest np PL i za każdym razem ktoś musi zmieniać po wejściu na stronę lub zapamiętać w sesji język na stronie głównej czyli www.superstrona.com i po prostu zrobić od razu przekierowanie, które nie powinno być jakoś bardziej zauważalne na dany lang.

Czyli mając zapisane w sesji: lang = it
ktoś wchodząc na www.superstrona.com zostaje od razu przekierowany na www.superstrona.com/it/home

Może Ci to trochę rozjaśni umysł.

[adbacz]

Rozwiązanie Szymciosek jest w porządku. Pod warunkiem, że nie posiadasz więcej niż jednej domeny.

W Twoim przypadku możesz zastosować pewien myk. To znaczy, zamiast używać sesji PHPowskiej tak: $_SESSION['key'] = 'val';, możesz napisać klasę do zarządzania sesją i przechowywać sesję w bazie danych. W tedy pobierasz tylko dane użytkownika: przeglądarka, IP, i wiesz kto to, na podstawie tych danych, więc bez problemu - możesz zastosować tą samą sesję, która była pod inną domeną.

To rozwiązanie daje Ci duże pole do popisu, bo w razie czego, wystarczy zmiana jednej linijki w klasie zarządzania sesją, i juz możesz spowrotem trzymać sesję domyślnie, czyli w $_SESSION.

W tedy, języki ustalasz sobie na podstawie domeny, a nie części adresu URI. Musisz wziąc jednak pod uwage pewna rzecz. Mianowicie, czy linki ze wzgledu na język będą sie mieniać czy nie?

domain.pl/kontakt
domain.de/kontakt
domain.en/contact
itp....

Bo jeśli tak, to musiałbyś się zastanowić, na jakiej zasadzie chcesz zrobić ewentualną zmianę języka, jesli uzytkownik będzie tak chciał. Ponieważ, użytkownik wchodząc na domenę pl, a później chcąc zmienić język na angielski, pod przykładowym adresem wymienionym powyżej nic nie zobaczy, jeśli nie zmieni się ścieżka do tego kontaktu.

Mam nadzieje, że rozumiesz o co mi chodzi.

Z drugiej strony - co w takim razie z wyszukiwarkami? Jesli chcesz eksportować swoją stronę na inne rynki niż polski, warto by było zmieniać też język w ścieżkach, tak jak jest to w przytoczonym przykładzie. W tedy na prawdę musiałbys poważnie się zastanowic, jak bys chciał, aby było. W tedy myslec nad rozwiązaniem.

Tego problemu jest kilka rozwiązań, musisz się tylko zastanowić, które Ci będzie odpowiadało, i które sprawi Ci najmniej kłopotów - dużym zyskiem. Przez zysk mam na mysli dobrze pozycjonowanie.

[tabbi]

Dużo rozmyślaliśmy nad optymalnym rozwiązaniem. Celem na początku serwisu jest rozreklamowanie tego na innych rynkach, a niestety google szybciej indeksuje url w domenach krajowych. Dlatego to było priorytetem w trakcie tworzenia aplikacji. Kolejnym ważnym aspektem jest prosta struktura. Jako, że serwis pozwala na tworzenie kont użytkowników, żeby to wszystko scalić wydelegowaliśmy jedną domenę, która będzie temu służyć tzn. jest to główna domena (np. example.com) do której użytkownik zostaje przekierowany i później jako już zalogowany wyświetla treść serwisu w swoim języku (oczywiście jeśli dostępny) i tak właśnie się to robi dla serwisów z wieloma domenami!

Problem ścieżek został rozwiązany następująco otóż dzięki application/config/routes.php budujemy tablicę ścieżek w następujący sposób:

[PHP] pobierz, plaintext 
// en-US Routes
$route['en-US']['default_controller'] = "welcome";
$route['en-US']['404_override'] = '';
[PHP] pobierz, plaintext 

Stąd po odczytaniu języka ładowany jest odpowiedni kod i dla konkretnej domeny ma konkretne ścieżki dostępne więc nie będzie już problemu z duplikacją treści dla dwóch tych samych ścieżek: example.pl/logowanie example.de/logowanie tylko example.pl/logowanie i example.de/einloggen

By zachować pewną przejrzystość ścieżki na głównej domenie czyli example.com są w języku angielskim ale tutaj treść oczywiście może być wyświetlana w różnych językach!

Implementacja

Skoro korzystamy z różnych domen więc $_SESSION odpadają propozycja "adbacz" na temat przechowywania danych o użytkowniku w bazie danych ("W tedy pobierasz tylko dane użytkownika: przeglądarka, IP") dla dużych serwisów a taki docelowo ma być ten serwis mija się z celem bo zajedziemy bazę. Do tego celu użyto jeden warunek, który jest dodany w application/core/MY_Router.php (nadpisujemy główny router i metodę _set_routing()):

[PHP] pobierz, plaintext 
// Lang detection : cookie, domain
        if($this->lang_default_domain == self::_get_host())
        { // check cookie or web browser if default domains is visited
            $this->detect_language_pure();
        }
        else
        { // detect domains
            $this->detect_language();
        }
[PHP] pobierz, plaintext 

Idea tego zastosowania polega na tych trzech wariantach:

Przykład 1

Użytkownik wchodzi na stronę example.pl wykrywana jest domena pl na podstawie pliku konfiguracyjnego mapowana jest domena wraz z kodem języka czyli dla pl jest to pl-PL. Następnie mapowany jest kod języka z nazwą katalogu w application/languages (czyli dla pl-PL -> polish) i nadpisywane jest pole languages w głównym pliku konfiguracyjnym config/config.php

[PHP] pobierz, plaintext 
$config['languages'] = 'polish';
[PHP] pobierz, plaintext 

Przykład 2

Użytkownik wchodzi na stronę example.pl wykrywana jest domena pl na podstawie pliku konfiguracyjnego mapowana jest domena wraz z kodem języka czyli dla pl jest to pl-PL. Następnie wybiera okno logowania i klika zaloguj się, zostaje przekierowany na domyślną stronę dla zalogowanych użytkowników example.com. Tutaj schemat działania jest nieco inny gdyż na początku wykrywana jest domena jeśli example.com to sprawdzamy czy istnieje cookie (cookie jest tworzone na stronie example.com podczas zmiany języka na inny, tutaj nie ma przekierowań na domeny!), jeśli nie wykryjemy cookie sprawdzamy język i na podstawie tych informacji ładujemy język strony!
Ten schemat działa tylko jeśli użytkownik nie jest zalogowany!

Przykład 3

Jeśli użytkownik zalogowany to w konstruktorze biblioteki Autryzacji jest pobierany język z ustawień (z bazy danych) użytkownika i nadpisywany jest główny domyślny język! Jest to pierwsza biblioteka jaka jest ładowana w całej aplikacji.

Przepływ treści w aplikacji:

[HTML] pobierz, plaintext 
DEBUG - 2013-03-09 19:43:40 --> Config Class Initialized
DEBUG - 2013-03-09 19:43:40 --> Hooks Class Initialized
DEBUG - 2013-03-09 19:43:40 --> Utf8 Class Initialized
DEBUG - 2013-03-09 19:43:40 --> UTF-8 Support Enabled
DEBUG - 2013-03-09 19:43:40 --> URI Class Initialized
DEBUG - 2013-03-09 19:43:40 --> Router Class Initialized
DEBUG - 2013-03-09 19:43:40 --> Routes Config Initialized
DEBUG - 2013-03-09 19:43:40 --> No URI present. Default controller set.
DEBUG - 2013-03-09 19:43:40 --> Output Class Initialized
DEBUG - 2013-03-09 19:43:40 --> Security Class Initialized
DEBUG - 2013-03-09 19:43:40 --> Input Class Initialized
DEBUG - 2013-03-09 19:43:40 --> Global POST and COOKIE data sanitized
DEBUG - 2013-03-09 19:43:40 --> Language Class Initialized
DEBUG - 2013-03-09 19:43:40 --> Loader Class Initialized
DEBUG - 2013-03-09 19:43:40 --> Database Driver Class Initialized
DEBUG - 2013-03-09 19:43:40 --> Session Class Initialized
DEBUG - 2013-03-09 19:43:40 --> Helper loaded: string_helper
DEBUG - 2013-03-09 19:43:40 --> Session routines successfully run
DEBUG - 2013-03-09 19:43:40 --> Auth Class Initialized (ładowanie w konstruktorze języka)
DEBUG - 2013-03-09 19:43:40 --> Language file loaded: language/polish/auth_lang.php
[HTML] pobierz, plaintext 

Podsumowując wszystko
Podobne zachowanie możemy zaobserwować dla serwisu facebook.com, pl-PL.facebook.com (schematy działania)

Ten post edytował tabbi 11.03.2013, 23:55:57

[Fifi209]

Kto pyta nie błądzi, ale można POSZUKAĆ skoro nie jest daleko

Temat: Wielojezykowosc