kde-i18n

Piotr Szyma?ski djurban w averne.net
Wto, 1 Kwi 2003, 15:43:59 CEST


Tomasz Kłoczko (Tuesday 01 of April 2003 15:10)
> Podsumuję .. moim zdaniem to co jest KDE to tylko przedsmak tego co może
> się dziać w innych aplikacjach jeśli chdozi o proporcje kodu wykonywalnego
> i plików niezbędnych do dziąłanai aplikacji do dokumentacji, komunikatów i
> tłumaczeń tego.
Racja, zreszta to jzu wyszlo poza KDE (np. openoffice).

> rozwiązań _dalej_ dyskutować nad tematem. Można też w każdej chwili uznać
> że temat jest chwilowo wieszany na haku aż ktoś nie znajdzie inengo ale
> jednak spójnego podejścia.
Wspolne podejscie. Przejde na ogolny sposob myslenia. Zalozmy ze x,y to 
aplikacje ktorych pliki i18n w postaci skompilowanej zajmuja wiecej miejsca 
niz same aplikacje. Nie trudno je sobie wyobrazic np. KDE, OO. Ale pojdzmy 
dalej bo przeciez mozemy miec do czynienia z taka sytuacja ze dokumentacja 
zajmuje kilkakrotnie wiecej niz pliki gui, a ktos jej nie chce.
Nalezaloby zatem przyjac takie wyjscia:
- dla pakietow roznych od x,y (czyli ktore nie zaliczaja sie do wwymienione 
grupy aplikacji), robimy normalne podpakiety w %lang .gmo do gui, w %doc 
htmle i inne dokumentacje
- dla pakietow x,y:
 + kde-i18n-<lang>-gui
 + kde-i18n-<lang>-doc
Dlaczego? Otoz problem jest nie tylko z laczem czy wielkoscia pliku. Chodzi o 
elastycznosc. To ze mozemy miejsce marnowac na dysku bo mamy 220gb i niewiele 
nam zalezy na tych 20mb, nie znaczy ze powinnismy to robic. W tym przypadku 
kazdy dostanie jezyk ktory chce, np. do gui, bo normalnie klika po polsku, 
ale np. niektorych progsow nie ma po polsku, a po niemiecku sa to sobie 
ustawia fallback na kde-i18n-de i juz ma po niemiecku, bo anglika ni w zab 
nie rozumie.  Zreszta po co mam sciagac (nawet jesli mi obojetny rozmiar) to 
czego nie potrzebuje? 
Tak wyrazne rozroznienie nie tylko ulatwia maintainowanie aplikacji x jako 
calosci, ale takze wyraznie ja oddziela od i18n, co jest bardzo wazna zaleta.

> Rozumiem potrzeby czy obiekcje osób z "cieńszą rurą" ale także wiem że
> spójne podejście do całej klasy zasobów w tym wypadku oparty o używanie
> %lang() czy wybór co do instalowania dokumentacji czy nie, upraszcza
> bardzo mocno gospodarkę zasobami. 
Tak, ale jest wysoce nieefektywny.

> Przyznam że z tego punktu widzenia
> używania tych zaobów i uwzględnieniu tego że "bandwich problem" będzie
> raczej zanikał niż się nasilał uważam, że rozwiązanie jakie wypracowane
> zostało przy okazji KDE 3.0.x jest najlepszym z obecnie znanych i takim
> które traktuje te zasoby dokładnie w taki sam sposób jak resztę (jak
> choćby GNOME). Znowu .. to wszytko do momentu aż ktoś nie wymysli czegoś
> co będzie lepsze :)
Nie jest. Bandwicz problem nie zniknie u nas ot tak z dnia na dzien, a poza 
tym zawsze efektywniej jest sciagnac 2mb tego co potrzebne niz 10mb tego co 
nie.

PS. Mussze poprawic to co Tomek napisal o kde. Nie wiem jak w kde-i18n bylo 
przed wersja 2.0, ale zapewniam cie ze jest teraz zdeka inaczej niz jak to 
opisales. 1.) nie ma zadnych htmli (wszystko jes generowane podczas 
kompilacji z docbookow) 2.) tlumacze nie sa rozdzielani od kde, na kazdy team 
przypada kilka kont w cvs w zaleznosci od potrzeb (np. venda i zulu maja 
lacznie jedno, bo jedna osoba koordynuje oba jezyki; my mamy 4, a niemcy np. 
3) i te osoby maja dostep rw kde-i18n. W teorii, wpraktyce wszyscy z tych 
ktorzy maja konta rw w cvs z ramienia kde-i18n dostali access do wszystki 
modulow, bo oni wielokrotnie poprawiaja jakeis rzeczy w roznych sourcach itp, 
albo np. podczas pisania dokumentacji wylapuja luki, dodaja wartosciowe 
rzeczy. W kde-i18n jest 30 tlumaczy, wyobraz sobie ze tak 48x30 dostaje konta 
w cvs kde, balagan gwarantowany.

-- 
Piotr Szymanski
djurban w averne.net



Więcej informacji o liście dyskusyjnej pld-devel-pl