Ik lees regelmatig teksten die geheel bestaan uit “woorden” met maar een lettergreep die totaal onleesbaar zijn. Overigens zitten er dan meestal ook geen hoofdletters en leestekens in, moet ik eerlijk toegeven. Dus het aantal zinnen wordt dan één. Maar gelukkig is het aantal woorden dan in de regel weer zo klein dat de (on)leesbaarheid er niet echt onder lijdt.

Zaken als interpunctie en “moeilijke” woorden (niet beperkt tot jargon) hebben een veel grotere impact op de leesbaarheid, en EULA’s zitten vol met woorden die je in een normaal gesprek niet snel tegenkomt.

Ik ben het wel eens met Juerd: leesbaarheid is niet alleen maar een “score”; je kunt die score natuurlijk wel als basis gebruiken. Zie het maar als een soort van vuistregel.

(*) Juridisch voor “uitsluiting van aansprakelijkheid”. Ironisch genoeg is het jargon dus leesbaarder dan de gewone termen.

En ik hoor net dat ik de twee constanten 77 en .93 heb omgewisseld. Implementatiedetail

http://www.dutchgrammar.com/nl/?n=SpellingAndPronunciation.05

• ambtenaar amb-te-naar niet: am-bte-naar

Wie verveelt zich en bouwt even een Perlscript?

Ik zal anders wel even kijken of ik er een scriptje van kan maken.

Ik laat het hier weten zodra hij bruikbaar is.

Ik heb nu als tweede coëfficiënt 7,7 genomen, 77 kan echt niet kloppen want dan is bij een woord of drie per zin je leesbaarheid al volledig geruïneerd.

En zet je je broncode nog ergens online?

Dit heb ik er alvast doorheengehaald:

* Disclaimer/privacybeleid van mijn eigen website: 45
* Licentie van deze blog (CC-BY-SA 2.5): 36
* Algemene voorwaarden van Google AdSense: 33

Werkt verslavend dit. Overigens wel moeilijk om een goede score te halen. Met mijn eigen score heb ik eigenlijk nog valsgespeeld omdat er webadressen in staan waardoor het aantal zinnen te hoog wordt ingeschat.

De uitleg heeft een leesbaarheid van 58, dus jullie zouden het moeten kunnen begrijpen.

(Excuus voor de driedubbelpost overigens.)

Ik zat nog te denken aan een jargonlijst, een soort van zwarte lijst zeg maar die strafpunten geeft als je moeilijke juridische woorden gebruikt. Dat is erger dan een gewoon moeilijk woord.

http://office.microsoft.com/en-us/help/HP101485061033.aspx

(Er zullen vast uitzonderingen op zijn: is een beamer iets dat beamt of iemand die beaamt?)

De apostrof kan trouwens ook op een ontbrekende klinker wijzen (’s lands wijs en zo).

Wellicht kun je daar weer uitzonderingen op bedenken, maar ik vermoed dat een bepaalde fout (p

Veel woorden hebben meerdere betekenissen (loop: ik loop, de loop van de rivier, de loop van een geweer, in de loop van de geschiedenis, etc.) en het bepalen van de achterliggende betekenis is essentieel om de moeilijkheid van de tekst als geheel te kunnen bepalen. Zonder hier rekening mee te houden kan je enkel een schatting maken van de moeilijkheidsgraad. Niet dat een schatting niet nuttig kan zijn, maar het lijkt me belangrijk te benadrukken wat de beperkingen van zo’n meting zijn.

(De MLR van deze tekst is tussen de 9.53 en de 21.83. Indicatie benodigde woordvoorraad tussen de 9.53 x 1000 en de 21.83 x 1000 woorden)

Het echte probleem is natuurlijk dat er geen feedback gegeven wordt. Overigens lijkt dit me niet alleen een taalkundig maar ook een juridisch probleem: waarom heeft alleen de opsteller wat in te brengen in zo’n “overeenkomst”? Hoor je er als gebruiker niet ook iets over te kunnen zeggen? Misschien moeten we EULA’s laten keuren door een soort organisatie, de consumentenbond of zo. Zij zouden op zijn minst de taalkundige kwaliteiten ervan kunnen toetsen, maar misschien tegelijkertijd ook de juridische.

Pion, pioen, ion, bios, kiosk…?

Slecht plan dus.

Maar… er is toch helemaal geen “plan”? Slechts een paar opmerkingen over hoe EULAs duidelijker zouden moeten zijn — en een formule die een indicatie voor leesbaarheid geeft. (En die, zoals meedere malen hierboven is opgemerkt, achteraf moet worden toegepast en geen doel op zich moet zijn.)

Kan (onnodig) moeilijke taal een reden zijn om een contract/EULA, die wel correct is en op zich ook wel redelijk, ongeldig te laten verklaren?

“Het echte probleem is natuurlijk dat er geen feedback gegeven wordt.”

Het echte probleem is dat het schrijven niet aan professionals wordt overgelaten, om twee redenen. In de eerste plaats vanwege de kosten, maar in de tweede plaats ook omdat de opdrachtgever denkt dat schrijven makkelijk is, dat het iets is wat elke idioot kan. (En iets wat elke idioot kan heeft de neiging te leiden tot producten die duidelijk door idioten in elkaar zijn gezet.)

Moet een advocaat dan maar een copywriter inhuren? Waarom niet? Om het geld hoeft ‘ie het niet te laten. Laatst vroeg ik een advocaat wat zijn uurtarief was. Toen ik weer bijkwam… maar dat is voor een andere keer.

Arnout gaf overigens niet aan waarom hij leesbaarheid wil kunnen meten, dus concluderen (of suggereren) dat hij deze maat wil gebruiken om leesbaardere EULA’s te produceren is wellicht wat voorbarig.

Waarom wil je dit eigenlijk in Perl?
“Perl - The only language that looks the same before and after RSA encryption.” -Keith Bostic

Edit: Voor de Nederlandse Office Word handleiding:
http://office.microsoft.com/nl-nl/word/HP101485061043.aspx

“Omdat PHP nog harder zuigt en ik geen andere talen ken waarin je een beetje efficiënt dingen kunt bouwen om strings te manipuleren.” Je bedoeld zeker het UTF-8 probleem?
Perl is een prima taal, maar een hel om te leren. En je kan toch prima PHP gebruiken, als het maar werkt

Ik wil geen flamewar starten of iets maar, maar waarom dan perse Perl en niet C of iets dus vandaar.

Als je woorden moet breken over verschillende regels krijg je soms vreemde afbrekingen als ‘afb-rekingen’, je kan een woord alleen afbreken op lettergreep. In het Engels worden deze afbrekingen Hyphens genoemd de Hyphenator heeft een grote collectie woorden met de juiste afbreking, en dus lettergrepen van een woord (niet alles overigens).