[vertaling] vertaling van hylafax

[Benno Schulenberg]

Hendrik Maryns schreef:
> Benno Schulenberg uitte de volgende tekst op 12/23/-28158 08:59
> PM: 
> > En het is mooier om
> > zulke lange regels af te breken en flink wat spaties te
> > gebruiken zodat er goed leesbaar geheel onstaat ook op een
> > smallere terminal. Bijvoorbeeld:
> >
> > Gebruik: faxalter [-C] [-h server] [-a tijd] [-d getal] [-k
> > tijd]\n [-m modem] [-n waarschuwen] [-P prioriteit]\n [-t
> > pogingen] [-A] [-g] [-p] [-r] [-v] [-DQR]\n taakID...
>
> Kan ik dat expliciet doen dan?

Natuurlijk: je mag altijd een \n invoegen om ervoor te zorgen dat 
een lange regel op een geschikte plaats afgebroken wordt, want 
vertalingen kunnen soms een stuk langer zijn dan het origineel.

> Het is nogal moeilijk om te weten 
> hoe dat er op de commandolijn uitziet.

Als je KBabel instelt op het gebruik van een niet-proportioneel 
lettertype is het goed te zien.  Of anders kun je je bestand af en 
toe eens bekijken met vim of nano of iets dergelijks op Konsole.

> Moet ik bv. \t gebruiken, 
> of expliciete tabs, of spaties, of…?

Altijd spaties gebruiken.  Die \t's zien er niet uit, ze camoufleren 
de tekst en maken de uitlijning onzichtbaar, en expliciete tabs 
(^I) worden later door msgmerge omgezet in \t's.

> > Het gebruik van een expliciet ellipsisteken (…) vind ik
> > trouwens niet mooi voor commandoregelprogramma's.  Op een
> > terminal (die een vaste letterbreedte heeft) moet ik goed
> > kijken om het niet aan te zien voor een liggend streepje.
>
> Ja, ik vind dat ze maar eens een oplossing moeten vinden voor
> vastebreedtelettertypes,

Commandoregelprogramma's moeten gewoon kunnen werken op een simpele 
VT, ook als die tekens heeft van bijvoorbeeld slechts 8x7 puntjes.

> Het idee zal compleet onbruikbaar
> worden van zodra er wat meer Chinees aan te pas komt.

In het Nederlands hebben we geen Chinees nodig, en op een VT of een 
Konsole heeft hylafax geen Chinees nodig.  Het enige Chinees dat 
er eventueel uit komt zal te zien zijn in een grafsich venster of op 
de printer.

> Ik ben een Unicode-fan en purist, dus gebruik ik U+2026 en U+201c
> en U+201d.

Strikt genomen gaat het bij de drie puntjes in een 
gebruikssamenvatting niet om een ellipsis: er wordt niets 
weggelaten, het is geen weglatingsteken, maar een 
er-mag-meer-toegevoegd-worden-teken.  Als het echt een ellipsis 
was, dan zou het origineel ook wel "…" gebruiken.  Als je dus
een purist wilt zijn, zou je drie punten als drie punten moeten 
vertalen.

> >> msgstr "gebruik: %s [-t to] [-c commentaren] [-p #pagina’s]
> >> [-l doellocatie] [-m maxcommentaren] [-z maxcommentaarlen]
> >
> > Rare afkortingen uit het origineel beter niet overnemen:
> > [-p aantal_pagina's] [-m maximum_aantal_commentaren]\n
> > [-z maximum_commentaarlengte]
>
> Ok.  Is het niet erg dat het geheel dan veel langer wordt?

Lengte is van ondergeschikt belang: je kunt altijd afbreken met 
extra \n's.  Het belangrijkste is duidelijkheid.

> En lage streepjes of koppeltekens?

Losse woorden verbinden met liggende strepen, omdat het koppelteken 
al gebruikt wordt bij de opties.

> >> msgid "Cannot create temp directory %s"
> >> msgstr "Kon geen temp-map creëren %s"
> >
> > "Kon tijdelijke map %s niet creëren"
> >
> > Waarom eigenlijk alles in de verleden tijd?
>
> Ah, ik dacht dat dat een conventie was.  Daar was toch ook sprake
> van onlangs.  Maar het betekent uiteindelijk hetzelfde.

Het komt op hetzelfde neer, maar in sommige andere berichten 
gebruikte je wel de tegenwoordige tijd.  En mijn conventie is: 
altijd tegenwoordige tijd, ook als het origineel de verleden tijd 
gebruikt.

> >> msgid "undefined ECM"
> >> msgstr "niet-gedefinieerde ECM"
> >
> > In de rest vertaal je "undefined" als "ongedefinieerd".
>
> Ok, voorkeur?

De kortste en precieste: ongedefinieerd.

> >> msgid "Syntax error, expecting identifier"
> >> msgstr "Syntaxisfout, identificator verwacht"
> >
> > "Syntaxfout: een naam werd verwacht"
>
> Ah, daar hadden we bij Mozilla eens een discussie over: het moet
> toch echt syntaxis zijn in het Nederlands.

En toch gebruik ik, eigenwijs, overal "syntax".  :)

Over "syntaxis" zegt van Dale: 1 [taalk.] leer van het gebruik van 
de rede- en zinsdelen, van de woordvoeging en van de zinsbouw => 
zinsleer.

Maar de syntax van computertalen is toch eigenlijk niet iets 
taalkundigs -- het gaat niet om woorden of zinsdelen of zinsbouw, 
maar meest om de juiste plaatsing van wiskundige tekens.

Maar goed, het ging me niet om die "syntaxis", dat vind ik best, 
maar om "identificator", wat ik nog nooit gezien heb en niet zou 
begrijpen.

> >> msgid "Bad %s parameter value %u."
> >> msgstr "Verkeerde %s parameterwaarde %u."
> >
> > "Ongeldige waarde %2$u van parameter %1$s."
>
> Ah, dat is een interessant truukje: met %cijfer$letter kan je dus
> de volgorde van de argumenten omdraaien?

Precies.  Zie 'info gettext c-format' en 'info gettext sources 
c-format'.

> >> msgid "SEND data, %lu bytes"
> >> msgstr "ZEND gegevens, %lu bytes"
> >
> > Misschien "ZENDEN van gegevens..."?
>
> Ik heb zo mijn twijfels of het misschien niet om een html SEND
> gaat? Waarschijnlijk niet.  Maar je kan dat toch als een
> mededeling in de eerste persoon opvatten?

Geen idee wat er bedoeld wordt.  Als een bericht zo onduidelijk is, 
is het goed om een gebrek te rapporteren, opdat de programmeurs een 
de tekst verbeteren of een vertalercommentaar toevoegen die vertelt 
wat er precies bedoeld wordt: /* TRANSLATORS: hylafax is sending 
data */.  Kijkend in de programmatekst lijkt het om een soort 
debugging-printopdracht te gaan, dus vermoedelijk had deze tekst 
helemaal niet gegettexteerd moeten worden.

Maar als het onduidelijk is waarom het gaat, is onvertaald laten het 
beste.  Beter dat, dan het verkeerd vertalen.

Benno