slrn-pl vs. slrn

Arkadiusz 'Jo Joro' Sochala jojoro w poczta.onet.pl
Pon, 7 Sty 2002, 17:21:09 CET


 7.01.2002 pisze Tomasz Kłoczko (kloczek w rudy.mif.pg.gda.pl):

> On Mon, 7 Jan 2002, Arkadiusz 'Jo Joro' Sochala wrote:
> 
> >  4.01.2002 pisze Jarek Baczynski (jary5 w poczta.onet.pl):
> > 
> > > - Dokumentacja.
> > > Bardzo wiele (jak nie większość lub prawie wszystkie ;) plików w doc/ i
> > > podkatalogach, są przetłumaczone na język polski i umieszczone w
> > > podkatalogach pl/ danych katalogów.  Tyczy się to również bardzo
> > > obszernego manuala oraz ostatnio slrnfuns.
> > 
> > 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, 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 :-)

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

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

> 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)?

-- 
  -=[  Slrn-pl?  Tak!                                    ]=-
  -=[  Chcesz pomóc w rozwijaniu projektu?  Zapraszamy!  ]=-
  -=[                             http://www.slrn.z.pl/  ]=-



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