kde-i18n - a może w ten sposób:

[Tomasz Kłoczko]

On Tue, 1 Apr 2003, Paweł Gołaszewski wrote:

> On Mon, 31 Mar 2003, Tomasz Kłoczko wrote:
> > > Proszę, wyjątkowo przeczytaj wątek od początku, a nie od końca.
> > > 
> > > Streszczenie: kiedyś sam byłem za takim rozwiązaniem, ale aktualnie ze
> > > względu na wykładniczy wzrost wielkości i18n w kde, staje się
> > > przeciwnikiem.
> > Paweł .. zrozum dwie rzeczy:
> > - zasoby z tłumaczniami czy dokumentacja/helpty to płenoprawna część 
> >   aplikacji,
> > - w związku z tym, że owe zasoby tłumaczeń czy dokumentacji/helpów będą
> >   rosły szybciej w najbliższej przyszłości niż pliki z kodem wyklonywalnym
> >   oddzielanie ich od reszty to zawracanie kijem Wisły,
> > - to czysty przypadek, że w *całym* KDE wyodrębniono zasoby 
> >   dokumentacji/helpów i tłumaczeń tychże widać że zajmują one sporo i w 
> >   związku z tym w oczywisty sposób muszą świeżbieć palce żeby "coś z tym 
> >   zrobić".
> 
> Nie, to nie jest przypadek. To jest *dobrze* przemyślana decyzja. I 
> słuszna. Dlaczego ktoś używając tylko angielskiego ma na dysku trzymać 
> wieeeeele setek MB tłumaczeń m.in. do suahili ??

Bo na tej samej maszynce może się zalogować ktos kto akurat tego języka 
potzrebuje. Mając host dosępowy z kilkoma setrkami użytkowników wcale nie 
jest rzadkim to żeby ućytkownicy chcieli używac kilku języków (u mnie przy 
1.3k kont w użytku oprócz polskeigo jest francuzki, niemiecki, 
portugalski).

> Ludzie od gnome też dojdą do podobnego wniosku (BTW - ile tam jest 
> języków? Nie wydaje mi się, że wiele...) i wydzielą tłumaczenia jak im się 
> całość zacznie rozrastać.

Niedojadą bo tutajk pakiety zawsze były i będą nadal bardzo autonomiczne 
czyli że nawet core zestaw pakeitów może się dość mocnio zmieniać w czasie 
(częśc wypada inne wpadają).

> Zrozum, że pakowanie tego do tego samego rpm-a miało sens w 3.0 - teraz 
> przestaje mieć. To jest po prostu za wielkie.
>
> A tłumaczenia to nie pełnoprawne częsci pakietów. Przy tej wielkości to 
> kwiatek do kożucha.

No to jeszcze raz. Dokumentacja i tłumaczenia to pełnoprawne częsci
aplikacji. To nie są "zasoby inaczej" w związku z tym nie ma potrzeby
traktowanai ich w sposób wyjątkowy.

> > W świetle punktu ostaniego nie wdrożysz tegho typu podejscia w
> > aplikacjach np. GNOME (bo będzie to bardzo pracochłonne). Wyodebnianie
> > innego podejsćia do KDE będzie łamać ogólne reguły traktowanai zasobów z
> > punktu widzenia zarządzania nimi i/lub będzie tworzyć tutaj wyjątki.
> 
> Ludzie od KDE robią dosyć rozsądnie ze względu na wielkość tłumaczeń. 
> Widziałeś ile ta paczka ma???

Ludziom od KDE wyszło to jak o mówi znajomy niejako "przez luźne
flanelowe"  przy okazji tego, że koniecznei na samym poczatku chcieli na
poziomi cvs oddzielić tłumaczy i dokumentalistów od reszty developerów
dalej dostosowując wręcz procedurę całośic do tego (na czym dzisiaj
ciekrpią bo mouszą uzywać włśnych hakniętych wersji ac/am/lt).  
Przykładowo w GNOME nie ma takeigo "rasizmu" w zwiąku z tym doprowadzenie
nawet przypadkowo do takiej separacji jak w KDE nie jest możliwe. Więcej
.. Miguel czy inni czesto podkreślali, że osoby które przychodziły jako
dokumentaliści często wnoszą jednak coś w faktycznym kodzie i vice versa
czyli tymbardziej tego typu "segregacja" jak w KDE z ich punktu widzenia
jest niepraktyczna i nie licz na to że bęzie miała miejsce w nawet dość 
odległej perspektywie.
Pakeity wykorzysrujące tylko zasoby core KDE i core GNOME tym bardziej nie
zachowują się tak jak core KDE i tym bardziej tam na tego typu rodzielenie
nie ma co liczyć, a napewno dokumentacja i helpy i tłumaczenia tychże 
będą tam puchnąć.
Uwzględniając powyższe .. owa chęć separacji wynika li tylko z tego że 
zasoby są rozseparowane na etapie developmentu po to żeby oddzielić
dokumentalistów od reszty a nie dlatego, że zajmuja one dużo miejsca i że
jest tam dużo jezyków (na początku wcale tak dużo tego nie było a 
separacja była bo był to wynik załozenia w metodologi pracy nad całoscią 
KDE). Ergo: wcale ół podział nie musi sie propagować dalej. To że się 
propaguje jest wynikiem nie tego że zajmuje to (obecnie) sporo miejsca.


kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*