Witam,

Po raz kolejny podchodzimy do pisania aplikacji autorskiej w której
będzie możliwość dodawania dowolnej liczby wersji językowych.

Problem o który chcę pisać dotyczy rozwiązania zarządzania tymi wersjami
w panelu administracyjnym.
I tak podejścia są dwa.

1. Przy edycji menu, podstron, aktualności, galerii, produktów w
katalogu ofertowym wyświetlam np w formie tabów obok siebie wszystkie
wersje językowe.
Plusy: obejmuję daną treść w wszystkich językach, stosunkowo wszytko
dostępne jest pod ręką.
Minusy: przy większej liczbie wersji językowych robi się już galimatias;
Aby utworzyć podstronę, która będzie występowała tylko w jednej wersji
językowej muszę utworzyć ją we wszystkich i publikować(jest taka
funkcjonalność) tylko tą jedną. Dodatkowo niewygodnie objąć, co jest dla
której podstrony wypełnione (która wersja językowa) i co opublikowane.

2. Podejście. Mam globalnie zdefiniowane w sesji jaką aktualnie wersję
językową edytuję - i w modułach menu, podstron, etc...
wyświetlam tylko tą jedną. Czyli każda podstrona w wersjach językowych
jest niezależna od jej potencjalnego odpowiednika w innej wersji językowej.
Plusy: Przejrzystość, Mogę tworzyć dowolnie inne struktury niezależnie
od domyślnej wersji językowej.
Minus: w przypadku edycji jednej podstrony w wielu językach muszę
globalnie przełączać się między wersjami językowymi.

Na pewno zdarzyło Wam się napotkać podobny problem.
Którą opcję wybralibyście ?

wojtek

--
===> www.JuraInfo.pl

Jura Krakowsko-Częstochowska,
największa baza noclegowa, agroturystyka, pensjonaty ...

do góry

** crazy bejbi <t...@n...ma> wrote:

> Po raz kolejny podchodzimy do pisania aplikacji autorskiej w której będzie
> możliwość dodawania dowolnej liczby wersji językowych.

> Problem o który chcę pisać dotyczy rozwiązania zarządzania tymi wersjami w
> panelu administracyjnym. I tak podejścia są dwa.

> 1. Przy edycji menu, podstron, aktualności, galerii, produktów w katalogu
> ofertowym wyświetlam np w formie tabów obok siebie wszystkie wersje językowe.
> Plusy: obejmuję daną treść w wszystkich językach, stosunkowo wszytko dostępne
> jest pod ręką. Minusy: przy większej liczbie wersji językowych robi się już
> galimatias; Aby utworzyć podstronę, która będzie występowała tylko w jednej
> wersji językowej muszę utworzyć ją we wszystkich i publikować(jest taka
> funkcjonalność) tylko tą jedną. Dodatkowo niewygodnie objąć, co jest dla
> której podstrony wypełnione (która wersja językowa) i co opublikowane.

> 2. Podejście. Mam globalnie zdefiniowane w sesji jaką aktualnie wersję
> językową edytuję - i w modułach menu, podstron, etc... wyświetlam tylko tą
> jedną. Czyli każda podstrona w wersjach językowych jest niezależna od jej
> potencjalnego odpowiednika w innej wersji językowej. Plusy: Przejrzystość,
> Mogę tworzyć dowolnie inne struktury niezależnie od domyślnej wersji
> językowej. Minus: w przypadku edycji jednej podstrony w wielu językach muszę
> globalnie przełączać się między wersjami językowymi.

> Na pewno zdarzyło Wam się napotkać podobny problem. Którą opcję
> wybralibyście ?

Zobacz jak to jest zrobione w eZ Publish, nie jest to idealne, ale jest OK. Po
prostu masz jakiś język bazowy dla obiektu treści i dodajesz do każdego obiektu
tłumaczenia (translations).

Z wersjami językowymi to ja zauważyłem wdrażając kilka stron inny problem. Na
samym początku trzeba ustalić czego oczekuje klient, bo są dwa rodzaje
oczekiwań:

1. W zasadzie dwie różne witryny z pewną częścią wspólną - niektóre biznesy
chcą w nieco inny sposób prezentować swoje treści dla gości zagranicznych, a w
inny dla polskich. Moim zdaniem to złe podejście, ale z reguły biznes często
miewa jakieś sensowne "za", które najczęściej wymaga długiego tłumaczenia aby
je pojąć. ;)

2. Jedna witryna w której każdy jeden obiekt obowiązkow jest słowo w słowo
tłumaczony na kolejne języki - to jest moim zdaniem najlepsze podejście. W eZ
Publish można to fajnie ogarnąć workflowem - każdy nowy obiekt bez tłumaczenia
wskakuje na biurko tłumacza, każdy obiekt po zmianie też wskakuje na biurko
tłumacza, tłumacz (a może sobie siedzieć na drugim końcu świata) rozlicza się
na podstawie raportu generowanego z samego eZ. No nikt mnie nie przekona, że eZ
nie jest superrrr. ;)

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

Dnia Fri, 03 Apr 2009 22:03:23 +0200, crazy bejbi napisał(a):

> 1. Przy edycji menu, podstron, aktualności, galerii, produktów w
> (...)
>
> 2. Podejście. Mam globalnie zdefiniowane w sesji jaką aktualnie wersję
> (...)
>
> Na pewno zdarzyło Wam się napotkać podobny problem.
> Którą opcję wybralibyście ?

Sam sobie odpowiedziałeś :) Wszystko zależy od struktury - 1:1 czy
niekoniecznie. Z tym, że drugą wersję w razie potrzeby sprowadzisz do
pierwszej (tworząc powiązania), a w drugą stronę tego nie zrobisz.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

Ja to rozwiązałem zupełnie inaczej. Każda wersja językowa to niezależny
dokument lub menu lub struktura kategorii itp. Prawie nigdy w praktyce tak
nie jest, że jakaś wersją językowa jest odbiciem innej. Zawsze są różnice a
często nawet - drastyczne. Po drugie jeśli nawet w jakimś specyficznym
zastosowaniu zaistnieje potrzeba skojarzenia odpowiedników językowych danego
dokumentu to takie skojarzenie można stworzyć albo za pomocą tabeli relacji
dokumentó w bazie danych albo np. schematami (np. PostgreSQL oferuje coś
takiego).

do góry

Dnia 03-04-2009 o 22:03:23 crazy bejbi <t...@n...ma> napisał(a):

> 1. Przy edycji menu, podstron, aktualności, galerii, produktów w
[...]
> 2. Podejście. Mam globalnie zdefiniowane w sesji jaką aktualnie wersję

Użytkownicy Twojego systemu będą wielojęzyczni i wklepią dla danej
strony wszystkie wersje językowe od razu, czy raczej do każdego języka
będzie dedykowana jedna osoba?
Strona będzie miała tą samą treść we wszystkich językach (artykuły np.)
czy raczej każda wersja będzie miała własną strukturę?

IMO te pytania dają Ci odpowiedź na powyższe. Jeśli odpowiesz "nie wiem",
"to zależy", "różnie" -- to zrób obie wersje, wszak to tylko kwestia
interface`u (a z tego co zrozumiałem, to wystarczy wyłączyć kilka zakładek
w przypadku wersji drugiej)

--
Maciej Łebkowski

do góry