Re: manpages-nl split
On Tue, Mar 20, 2001 at 08:45:34PM +0100, josX wrote:
> Jama Poulsen wrote:
> > On Mon, Mar 19, 2001 at 03:04:43PM +0100, Joost van Baal wrote:
> > > [19-Mar:13:59 |jama] btw, ik denk dat ik het niet eens ben met
> > > je manpages-nl splitup voorstel
> > > [19-Mar:13:59 joostvb] stuur maar mailtje dan
> > > Waarom niet eens?
> >
> > Ik denk dat het aanmaken van verschillende taal specifieke
> > manpages per package niet de juiste oplossing is. Het
> > probleem zit hem volgens mij op een hoger nivo:
> >
> > Hoe ga je om met taal specifieke documentatie voor de
> > 'non-required' (Debian) software?
> >
> > Manpages zijn vaak maar een (klein) onderdeel van de
> > documentatie van een stuk software, je hebt:
> > - README's
> > - INSTALL's
> > - GNU Info-pages
> > - Web-pages
> > - In-program-help-files
> > (POT files zijn hier gebruikelijk,
> > http://i18n.kde.org/translation-howto/gui-translation.html)
> > - Configuratie file commments
> >
> > Als het doel is een 'dutch debian' box te maken, heb je
> > alleen aan manpages-nl niet genoeg. Het zou omslachtig
> > zijn enkel de manapges in het Nederlands te leveren, maar
> > de overige documentatie ergens anders vandaan moeten halen.
> >
> > Een idee zou zijn om een (optionele) documentatie extensie
> > te maken per package. Er zou dan naast een algemene
> > packager ook package vertalers zijn. Voorwaarde is
> > hierbij dat ze 'redelijk' onafhankelijk kunnen werken. De
> > 'versioning' bij belangrijke nieuwe releases zal dan wel
> > onderling moeten worden afgestemd. Een Debian vertalings
> > team zou hiervoor een infrastructuur kunnen opzetten.
> >
> > Vertalers zouden dan de /usr/share/doc documenten
> > kunnen vertalen en die vertalingen kunnen stoppen
> > in /usr/share/doc/nl. Hetzelfde geld voor de man-
> > en info-pages.
> >
> > Lastiger: 'included' configuratie files zouden mbv een
> > uniek taal-kenmerk kunnen worden aangeduid, upgrades van
> > configuratie files is dan wel veel lastiger lijkt me.
> >
> > De machine beheerder kan aangeven aan welke taal, naast het
> > 'required' Engels, moet worden gebruikt voor vertalaalde
> > debian packages.
> >
> > Voor de standaard 'linux' manpages is het onderscheidt
> > tussen gebruiker en ontwikkelaar voldoende, zoals sommige
> > manpage vertalingen al hebben.
> >
> > Ik zie ook in dat mijn voorstel nog rammelt aan alle
> > kanten, maar als het doel is de machine te laten gebruiken
> > door mensen die liever een ander dan engels lezen, zullen
> > we zoveel mogelijk relevante documentatie moeten kunnen
> > packagen en niet alleen de manpages.
> > -- Jama
>
> maw: per taal een compleet 'vertaald' pakket, waar alles
> in zit wat mogelijk is vertaald voor een programma (van
> README's tot .pot-files tot manpages en HOWTO's).
>
> Het is dus Joost's idee (1 manpage-$LANG-pakket per taal per pakket),
> maar uitgebreidt met alles wat als vertaling kwalificeert erin
> meegenomen.
>
> Dit lijkt me best wel een (heel) goed idee eigenlijk. Dat betekend
> kortere download voor het 'core' pakket (niet 10 onbruikbare
> .pot-files, manpages, enz.enz), en simpel kiezen van het
> gewenste X-${LANG}-translate pakket (dat kan mischien files
> overschrijven van het originele pakket als een patch-file).
>
> Het lost ook het probleem op van hoe vertalingen worden verspreidt,
> dat "het hoort eigenlijk bij de pakketten zelf in" is IMHO onuitvoerbaar.
> (
> Ga maar na: je schrijft een proggie, en krijgt ineens een japanse
> manpage in de bus, dan wil je natuurlijk weten of dat klopt, dus ga
> je emailen.... dus de vertaler krijgt mogelijk vele emails over elk
> klein vertalinkje (potentieel). Het kan ook de "zin" van de vertaler
> ondermijnen als hij voor elk handleidinkje naar `de pakket-baas' moet
> om het in te dienen.
> )
> Het 1 geheel laten van de manpages* pakketten is nu nog wel te doen
> maar een potentieel probleem als er veel vertaalde handleidingen komen
> voor ongeinstalleerde programma's (dit is nu nog vooral een theoretisch
> probleem, maar ondanks dat "niet netjes").
>
> Groeten Jos
>
> ps
> Dat ik eerder tegen split was kwam door sentimentele redenen, en
> onduidelijkheid wat het plan zou inhouden voor het project zelf.
Ik denk dat inderdaad het argument: "verspreiden vertalingen met
programma tarball zelf kan de zin van de vertaler ondermijnen" veel
hout snijdt.
De stand <splitsen> vs <bij elkaar houden> is op dit moment 2 - 3.
Cc debian-l10n-dutch, omdat daar denk ik ook wel wat geinteresseerden
zitten. Ik denk dat we deze discussie beter in het engels op
debian-i18n voort kunnen zetten, overigens.
Groeten,
--
Joost
Reply to: