slrn-pl vs. slrn

[Jarek Baczynski]

W poprzednim odcinku... (Arkadiusz 'Jo Joro' Sochala pisze):

>>> Przetłumaczona jest cała dokumentacja, za wyjątkiem VMS-SLRN.HLP,
>> To co jest w tej chwili w slrn-pl czyli w każdym podkatalogu w doc/ jest
>> podkatalog pl też jest dość głupie bo nie grupuje tego typu rzeczy. Wogóle
> Nie za bardzo zrozumialem sens tego zdania,

Chodzi o to, że polskie wersje plików są w podkatalogu pl/ każdego
katalogu z plikami oryginalnymi.  Mnie też to się mało podoba, bo troche
się jednak robi bałagan w tych wszystkich podkatalogach w doc/.

Kloczku, widzisz jakieś dobre rozwiązanie?

> ale my nie pisaliśmy tej
> dokumentacji - tylko ją tłumaczyliśmy. Po prostu przerzuciłem wszystko
> to co było w doc/ do doc/pl i wspólnymi siłami przetłumaczyliśmy.
> Jeśli jednak komuś sie chce napisać jakiś Tutorial-for-newbies to
> zapraszam :-)

Huehe.. ;)

>> z slrn-pl można sporo powywalać rzeczy które są autogenerowane przez
>> gettextize, autoconf, automake (wyleciec powinny wszystki Makefile.in,
>> wszystko po za POTFILES.in i *po z po/, katalog intl). Usunąłbym też cały
>> autoconf/ (to co jest autoconf/acinclude.m4 jest też udostępniane w
>> wiekszości przez makra które są/powinny być w zasobach systemowych).
>> Zamiast bawić sie wykrywanie co jak i czym kompilować w róznych 
>> środowiskach można użyć libtoola który włąsnie jest od tego żeby sobie 
>> takimi rzeczmi nie zaprzątać głowy.
> Rozumiem cię, ale to naprawdę nie jest nasza wina. Taki pakiet jest w
> oryginale - my dodaliśmy tylko kilka linijek do paru Makefile.am
> (instlacja doc/pl, makr i slrn*.rc). Jeśli sądzisz, że zrobisz to lepiej
> - śmiało - brakuje nam właśnie kogoś dobrze zaznajomionego a automake
> (itp.). 

Zaraz, chwila moment!!  Arku, właśnie doszliśmy do ładu z automake-iem
(poprawki do kilku Makefile.am), więc niech nikt teraz już tego nie
dotyka!  Przynajmniej nie _teraz_, kiedy staramy sie jak najszybciej
wypuścić kolejną wersję slrn-pl.

Zaraz będzie rok, jak nie wyszło nic nowego -pl, a obecnie projekt jest
już naprawdę w punkcie, gdzie większość jest dopięta na ostatni guzik.

Ogólna sugestia co do dalszej dyskusji.  Nowa wersja slrn-pl wyjdzie
naprawdę na dniach.  Do tego czasu, proponuję nie wprowadzać już _żadnych_
"strategicznych" zmian do projektu, bo znów opóźnimy się nie wiadomo o
ile.  Niech slrn-pl wyjdzie tak, jak jest (nawet, jeśli miałby być nie
wiadomo jak "zaściankowy").  Później zaczniemy włączać slrn-pl do PLD
jako osobny pakiet lub połączenie z istniejącym.

Ołkej?

> Jednak jest jeden problem slrn-pl nie powstaje tylko i wyłącznie dla
> PLD, ale ma się dać zbudować także na innych dystrybucjach.

Otóż to.  Udostępniamy też pakiet źródłowy "do samodzielnego montażu",
czy wywalenie takiego intl/ lub gotowych binarek po/*.gmo, nie spowoduje
potencjalnych problemów? (ludzie mogą instalować to na różnych systemach
nie zawsze wyposażonych we wszystkie potrzebne utilsy)

>> Jeżeli nikt z osób grzebiacych w slrn-pl nie miałby nic przeciowko to mogę
>> pomóc przynajmniej w wyczyszczeniu tego co jest autogenerowane przez 
>> narzędzia GNU.

Kloczku, patrz wyżej od słów "Zaraz, chwila moment!!" ;-)
Na razie wstrzymajmy się z tym.

> Jeśli tylko masz ochotę i jesteś w stanie mnie zapewnić, że po tej
> operacji slrn będzie się kompilował nadal bez większych problemów na
> innych dystrybucjach ze starszymi wersjami automake/libtool/itp... to
> zapraszam. Chętnie przyjmiemy twoją pomoc.

Arku, ty też patrz wyżej. :))
Powstrzymajmy się w tym momencie od _wszelkich_ kombinacji w projekcie.
Wyjdzie nowa wersja, polecimy dalej.

>> Po za tym jeżlei maintainer ma wątpliwości co do pewnych rzevczy które są 
>> obecnie (a wygląda że jest sporo dobrego) to można to olać i zacząć 
>> przyciągać innych (szczególnie inne nacje). Warunek: obecna wersja snrn-pl 
>> de facto musiałby zmienić się w slrn bez jakichkolwiek przymiotników.
>> Mamy już pam-a we włąsnej wersji i nie widże nic przeciwko temu żeby 
>> działo się coś podonego z innymi rzeczami o ile ilość modyfikacji 
>> przekracza pewne ilosci powyżej których zakąłdanie wąłsnego drzewka w cvs 
>> jest łatwieksze w dalszej konserwacji zasobów. W takim wpadku niemniej 
>> należałoby takze zrezygnować z komentowanai zmian po polsku żeby nie 
>> odstraszać innych/żeby było to dobrą platformą do wielonarodowej pracy 
>> nawet jżeli przez dłuższy czas nikt inny i tak nie miałby się od tego 
>> dokładać.
> 
> Już zrobiliśmy w tym celu pewne kroki - np tłumaczenie komunikatów makr
> na różne języki (by tsca), ale pierwotnie zaczynaliśmy od
> przygotowywania slrn dla _polskiego_ usera i to usera, który jest leniwy
> i/lub za wiele nie umie. 
> Poza tym jak wyobrażasz sobie sprawę wielojęzycznej dokumentacji i
> zarządzanie nią? Teraz mamy 2 jezyki i przetłumaczenie całości na pl
> zajęło nam ładnych arę miesięcy. A co będzie gdy języków będzie 10? I
> jaki będzie rozmiar pakietu 5MB (samego tekstu)?

Mnie też to ciekawi...

 -- Jarek

-- 
      Jarek 'Bacza' Baczyński            Delta: We never make the same mistake
    Odwiedź mnie w galerii... :-)        three times.   -- David Letterman 
 http://fanthom.irc.pl/~jarek/pyrypy/