kde-i18n

[Tomasz Kłoczko]

On Tue, 1 Apr 2003, Piotr Szyma?ski wrote:

> Tomasz Kłoczko (Monday 31 of March 2003 19:52)
> > Spokojnie. Jeżeli czujesz się osobiście urażony to pzrepraszam.
> > Tak .. nie czytałem tego co wtedy było poruszane.
> Sorki ponioslo mnie :) 
> Ale fakt ze tamto zabrzmialo jak oskarzenie, a specjalnie czekalem czy nie 
> bedziesz mial nic przeciwko tym zmianom.

Jeszcze raz przepraszam i jeszcze raz chciałbym podkreślić żeby nie
traktować mnie szczególnie (bo to nie o to chodzi) i nie dyskutować ze mną
czy się przepychać tylko żeby próbować podejmować dyskusję możliwie mocno
merytoryczną. Przy takich regółach gry mamy szansę nie "skakać sobie
nawzajem do oczu" .. po to żeby dalej tymi "oczami" móc niejako dalej
ogladać zagadnienia w mairę jak wszystkie strony dokładać będą jakieś
dodatkowe punky widzenia/argumenty.
Jest także szansa na to żeby uginać się jeżli już nied pod presją osoby
tylko pod presją argumentów i żeby to wszystko działo się w 
akceprowalny/cywilizowany sposób.

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.
Chodzi też o to żeby *jednak* nie tworzyć wyjątków w ogólnym podejściu do
danej klasy zasobów i żeby to ogólne podejście uwzględniało specyfikę 
tejże kalsy zasobów.
W tym sensie np. specjalne traktowanie np. kdebase czy innych tylko
wybranych kawałków uważałbym za błędne i prowadzące do ręcznego/często na
granicy jednosnacznej rozstrzygalności podejscia. Tego typu hazardów
różnego traktowania zasobów w ramach danej klasy powinniśmy już dla
własnej wygody choćby konserwacji całości jednak unikać.

Można z jednej strony stawiać czy korygować wymagania jakim powinna być
podporządkwoana forma danej klasy zasobu czy podejścia do tejże kasy.
Można także wobec braku pełnego zadowolenia z przyjętych z obecnych
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.

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. 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 :)

Co do tego co można zrobić to niewątpliwie trzebaby spróbować podyskutować
na rpm-list o trzymaniu statusu ustanień językowych per pakiet przy
upgrade.
Może jeszcze ktoś coś widzi ?

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*