Jag är intresserad av "Ugglan" och har läst "Hur man korrekturläser" ett antal gånger fram och tillbaka. Ett antal frågor/kommentarer och förslag har utkristalliserats. De är många men titta på dem ändå. De skulle underlätta (utom 4) för redaktionen och ändå inte öka editeringstiden med mer än någon promille.
1. Gåsögon. Längst ner på http://www.lysator.liu.se/runeberg/nfag/0011.html används ett "lågt citat" för dito-symbol. Dito går bara att använda i tabeller och uppräkningar. Vanligtvis skriver man ju nåt i stil med -||- , dvs inte ett speciellt tecken. Kan gåsögon användas för dito? ("citerad text där citerad text inte citeras"?)
2. Tabeller och tabell-liknande text (längst ner på http://www.lysator.liu.se/runeberg/nfag/0011.html). När tabeller flyttas till HTML är det enkelt om tabellen är "förberedd" tex med <tab> mellan varje kolumn (inkl de tomma). Förslag: tabellrad inleds med <tbr> och <tbk> mellan kolumnerna, kanske avslutande </tbr>. tabell-liknande rad med <tlr> och <tlk> etc
Även metrik/läsanvisningar kan betraktas som en tvåspaltig tabell och det synsättet ger inga problem vid konverteringen till HTML. Pre-editerings-HTML skulle kunna presentera som nu: nytt stycke för <Bir.>.
3. Inför införandet av unicode Främmande alfabeten borde inte translitteras då tex grekiska eta och epsilon blir båda e, = förstörelse av data. Märk istället de (ytterst sällsynt förekommande) orden med <grk>grekiska</grk> <heb>hebreiska</heb> <kyr>kyrilliska</kyr> <run>runor</run> etc
Specialtecken som <pund> och <skålpund> skulle kunna få vara sina egna taggar och senare konverteras till tex det kursiverade lb. för skålpund (finns i unicode?). Ett skript skulle kunna samla ihop de sidor som innehåller en viss tagg för en enda unicode-insats: sammanlagda mängden icke-redan-translitterade grekiska ord är bara ett A4.
Kvadrat som speciellt tecken har jag inte sett. Betydelse?
4. Märkning av sakfel. När dumheter i texten beror på att författaren skrivit fel (stavfel, slarvfel - särskilt årtal), eller när sättaren läst fel (slarvfel), "skrivit" fel på kända ord (slarvfel, stavfel) eller satt fel (sättningsfel - gärna årtal), bör slarvfelet rättas till, de talar ju bara om författarens/sättarens/sättningskastens egenheter och problem och kan i bästa fall bara ge kuriösa statistiska data.
Äkta sakfel ska stå kvar men skulle kunna märkas med <kommentar>Sardinien ingick inte i koalitionen förrän 1713</kommentar> som sen inte syns på pre-editeringssidorna men kan vara med i slutresultatet. Hit hör tex INTE idag felaktiska latinska namn eller resultat av nutida upptäckter, bara de uppgifter som inte stämmer med det de visste DÅ. Att hitta äkta sakfel kräver en oerhörd sakkunskap (och vetenskapliga referenser) men ibland editeras ju sidorna av experter (här har jag inga anspråk).
5. "The whole page is OK now" Det skulle kännas bättre om min färdigediterade sida tittas igenom minst en gång till, gärna två. Något fel slinker alltid förbi och det finns säkert de med hökögon som finner ett nöje att rätta texter som både OCR och editeringsproffs misslyckats med. "The whole page is really OK now". "The whole page is really, really OK now".
6. Författarsignatur <sign>P. W.</sign> gör det onödigt att sätta en massa mellanslag mellan textslutet och signaturen. De blir dessutom sökbara (sen). <s> är kortare och bättre?
Förresten, i månadssammanställningar står editör-signaturer. Var kommer de ifrån? Man knappar ju bara in e-postadressen. Skrivs den i Comment? Ett förslag i så fall: en cookie med signaturen (jobbigt för dem för dem med flera alter egon :)
7. Editering i praktiken Jag har brukat kopiera texten-att-editera, (med förnuft) stavningsrätta den i Word, kopiera och klistra in i editeringsrutan.
Bläddraren (the browser) hanterar sin teckentabell och KAN konvertera det kopierade. Operativprogrammet konverterar (ganska säkert) det kopierade. Word konverterar det kopierade (och hittar på en mängd dumheter om de "smarta" funktionerna inte är desarmerade). Operativprogrammet konverterar... Bläddraren konverterar...
Alla dessa konverteringar löper amok med radbrytningarna och de radbrytningar som kommer tillbaka till rutan bör väl inte vara de som startades med? Jag förutser senare problem och föreslår deklaration av den återvändande texten: en hemsida kan ge analyser av dina retursidor och ge dig en cookie som deklarerar dina returer i fortsättningen. Om man byter ascii-tabell, språkkodning och tangentbord varje timme blir det förstås problem :) Observera att problemet för åäö är betydligt större.
Nu kan jag förstås hittat på en lösning till ett problem som inte finns (IT-världens affäridé :) Det kanske bara behövs som en diagnos för väldigt udda hård- & mjukvarukombinationer.
Hur kommer Unicode 8 att påverka detta? Inga (?) operativsystem och få ordbehandlare kan hantera Unicode.
8. Alla nya fina taggar? På varje <skålpund> går det säkert 1000 <i> = liten arbetsinsats, och om man vill byta till skålpund är det OMÖJLIGT att sedan hitta alla nya skålpund som varit ett tecken - utan minskad arbetsinsats. Det är enkelt att senare automatiskt ändra oönskade taggar, tex för pre-editeringssidan, med perl-skript. Nya taggar måste förstås väljas så att de inte krockar med HTML, XML etc.
mvh, bob
sön 2004-12-05 klockan 14.30 skrev Bengt-Olof Bjurman:
Jag är intresserad av "Ugglan" och har läst "Hur man korrekturläser" ett antal gånger fram och tillbaka. Ett antal frågor/kommentarer och förslag har utkristalliserats. De är många men titta på dem ändå. De skulle underlätta (utom 4) för redaktionen och ändå inte öka editeringstiden med mer än någon promille.
Jag nöjer mig med att svara på de punkter där jag har en färdig åsikt.
- Tabeller och tabell-liknande text (längst ner på
http://www.lysator.liu.se/runeberg/nfag/0011.html). När tabeller flyttas till HTML är det enkelt om tabellen är "förberedd" tex med <tab> mellan varje kolumn (inkl de tomma). Förslag: tabellrad inleds med <tbr> och <tbk> mellan kolumnerna, kanske avslutande </tbr>. tabell-liknande rad med <tlr> och <tlk> etc
Även metrik/läsanvisningar kan betraktas som en tvåspaltig tabell och det synsättet ger inga problem vid konverteringen till HTML. Pre-editerings-HTML skulle kunna presentera som nu: nytt stycke för <Bir.>.
Det låter för komplicerat, tycker jag.
- Inför införandet av unicode
Främmande alfabeten borde inte translitteras då tex grekiska eta och epsilon blir båda e, = förstörelse av data. Märk istället de (ytterst sällsynt förekommande) orden med <grk>grekiska</grk> <heb>hebreiska</heb> <kyr>kyrilliska</kyr> <run>runor</run> etc
Unicode är nog bra, och vi kommer antagligen att gå över till det. Någon gång. Håll inte andan medan ni väntar, bara. Jag tycker att det är en bra idé att skriva <grekiska>slainte</grekiska> och liknande. Det är som du säger inte ofta det förekommer, så jag tycker att det är fritt fram att använda det med en gång så får vi i redaktionen se till att hantera det när det blir aktuellt att ta hand om det verket. Som synes tycker jag däremot att man gott kan skriva ut hela språknamnen (de förekommer ju som sagt inte ofta, så det är inte mycket merjobb det handlar om, men det blir lättare både att läsa och att komma ihåg). Skriv gärna en kort kommentar i kommentarsfältet om att du använder dessa taggar på de sidor där det är aktuellt.
Specialtecken som <pund> och <skålpund> skulle kunna få vara sina egna taggar och senare konverteras till tex det kursiverade lb. för skålpund (finns i unicode?). Ett skript skulle kunna samla ihop de sidor som innehåller en viss tagg för en enda unicode-insats: sammanlagda mängden icke-redan-translitterade grekiska ord är bara ett A4.
Se föregående kommentar.
- Märkning av sakfel.
När dumheter i texten beror på att författaren skrivit fel (stavfel, slarvfel - särskilt årtal), eller när sättaren läst fel (slarvfel), "skrivit" fel på kända ord (slarvfel, stavfel) eller satt fel (sättningsfel - gärna årtal), bör slarvfelet rättas till, de talar ju bara om författarens/sättarens/sättningskastens egenheter och problem och kan i bästa fall bara ge kuriösa statistiska data.
Äkta sakfel ska stå kvar men skulle kunna märkas med <kommentar>Sardinien ingick inte i koalitionen förrän 1713</kommentar> som sen inte syns på pre-editeringssidorna men kan vara med i slutresultatet. Hit hör tex INTE idag felaktiska latinska namn eller resultat av nutida upptäckter, bara de uppgifter som inte stämmer med det de visste DÅ. Att hitta äkta sakfel kräver en oerhörd sakkunskap (och vetenskapliga referenser) men ibland editeras ju sidorna av experter (här har jag inga anspråk).
Här har vi policyn att faktafel står för den som skrev verket ursprungligen, och ska stå kvar. Sättningsfel har det varit lite si och så med. Jag föredrar om de inte ändras, eftersom det är svårt att veta vad som verkligen är ett sättningsfel. Vad som däremot är OK att göra är att införa de rättelser som ibland kommer på sista sidan i den löpande texten.
- "The whole page is OK now"
Det skulle kännas bättre om min färdigediterade sida tittas igenom minst en gång till, gärna två. Något fel slinker alltid förbi och det finns säkert de med hökögon som finner ett nöje att rätta texter som både OCR och editeringsproffs misslyckats med. "The whole page is really OK now". "The whole page is really, really OK now".
Just nu kräver våra script att varje sida i ett kapitel ska ha varit märkt "whole page OK" av minst en person för att godkännas. Jag håller med om att det är bättre om fler personer kollar en sida, och det kan mycket väl tänkas att det framöver kommer att ändras så att ett kapitel inte flyttar upp till att bli klart förrän minst två personer godkänt varje sida som klar (även om det inte behöver vara samma personer för varje sida).
Förresten, i månadssammanställningar står editör-signaturer. Var kommer de ifrån? Man knappar ju bara in e-postadressen. Skrivs den i Comment? Ett förslag i så fall: en cookie med signaturen (jobbigt för dem för dem med flera alter egon :)
Signaturen är helt enkelt användarnamnet i epostadressen. I några fall vet vi att en person använder flera epostadresser och slår i så fall ihop summeringen.
Det finns planer på att införa någon form av inloggning, så att webbsidan kan komma ihåg vem det är som korrigerar en sida så att man ska slippa att knappa in det själv.
Inga (?) operativsystem och få ordbehandlare kan hantera Unicode.
Linux kan, vad jag vet.
Hans
- Inför införandet av unicode
Främmande alfabeten borde inte translitteras då tex grekiska eta och epsilon blir båda e, = förstörelse av data. Märk istället de (ytterst sällsynt förekommande) orden med <grk>grekiska</grk> <heb>hebreiska</heb> <kyr>kyrilliska</kyr> <run>runor</run>
Jag tycker att det är en bra idé att skriva <grekiska>slainte</grekiska> och liknande. Som synes tycker jag däremot att man gott kan skriva ut hela språknamnen.
Nu hänger jag inte riktigt med. Är det språk eller icke-latinska skriftsystem som skall markeras? Om jag citerar ett grekiskt ord med latinska bokstäver i en svensk text, ska det då markeras med <grekiska>? Om jag cterar ett svenskt ord med grekiska bokstäver ska det då markeras med <grekiska>? Det vore en finess att kunna ange språket och sen få lang-attribut i html-koden. Att ange ett skriftsystem med det mest vanliga språket som använder skriftsystemet oavset om ordet är skrivet på det språket verkar att bädda för missförstånd...
Christer
Bengt-Olof Bjurman skrev:
- Gåsögon. Längst ner på http://www.lysator.liu.se/runeberg/nfag/0011.html används ett "lågt citat" för dito-symbol. Dito går bara att använda i tabeller och uppräkningar. Vanligtvis skriver man ju nåt i stil med -||- , dvs inte ett speciellt tecken. Kan gåsögon användas för dito? ("citerad text där citerad text inte citeras"?)
Ja, gåsögon (») kan användas som nedflyttningstecken. Man kan också använda två apostrofer (''). Vi har inte ansträngt oss för att skapa någon standard för hur man ska göra.
- Tabeller och tabell-liknande text (längst ner på http://www.lysator.liu.se/runeberg/nfag/0011.html). När tabeller flyttas till HTML är det enkelt om tabellen är "förberedd" tex med <tab> mellan varje kolumn (inkl de tomma). Förslag: tabellrad inleds med <tbr> och <tbk> mellan kolumnerna, kanske avslutande </tbr>. tabell-liknande rad med <tlr> och <tlk> etc
Detta säger jag bestämt nej till. Vi ska inte uppfinna vårt eget invecklade uppmärkningsspråk. Det är illa nog att vi har behövt införa våra egna markeringar för spärrad stil (<spärr>) och indrag (<tab>). Redan börjar det bli lite komplicerat i överkant, och för att få fler medhjälpare bör vi i stället anstränga oss för att förenkla.
- Inför införandet av unicode
Främmande alfabeten borde inte translitteras då tex grekiska eta och epsilon blir båda e, = förstörelse av data. Märk istället de (ytterst sällsynt förekommande) orden med <grk>grekiska</grk> <heb>hebreiska</heb> <kyr>kyrilliska</kyr> <run>runor</run> etc
Återigen lägger jag in mitt veto mot sådana <grk>-taggar. Unicode kommer att lösa problemet och i väntan på det kan man låta de grekiska bokstäverna ligga.
Kvadrat som speciellt tecken har jag inte sett. Betydelse?
I stället för att skriva ut kvadratfot står det ibland tryckt något som ser ut som [_]ft, dvs en liten kvadrat före ft.
- Märkning av sakfel.
När dumheter i texten beror på att författaren skrivit fel (stavfel, slarvfel
- särskilt årtal), eller när sättaren läst fel (slarvfel), "skrivit" fel på kända ord (slarvfel, stavfel) eller satt fel (sättningsfel - gärna årtal), bör slarvfelet rättas till, de talar ju bara om författarens/sättarens/sättningskastens egenheter och problem och kan i bästa fall bara ge kuriösa statistiska data.
Nej, absolut inte. "Dumheter i texten" kan ju vara allt upp till skapelseberättelsen i Bibeln ("rättat till Darwins version"). Min erfarenhet av 12 år med Projekt Runeberg säger mig att det inte går att dra någon skarp gräns mellan "uppenbara" tryckfel och avvikelser i stavning och åsikter. Nyligen fick jag rätta tillbaka "Oljoberget" som någon hade "rättat" till "Oljeberget". Men det ska faktiskt stå "Oljoberget" med "o". Och rörande årtal och datum kan vi ju bara ta en sådan sak som slaget vid Lützen, som alla svenskar "vet" inträffade den 6 november, men som enligt vetenskapen ägde rum den 16 november enligt vår nuvarande tideräkning ("nya stilen", gregorianska kalendern). Den enda rekommendation som jag kan utfärda är: Låt dumheterna stå! Återge den tryckta texten!
Detta är alltså min rekommendation. Sedan kan man givetvis använda sitt eget omdöme, men då riskerar man att få smäll på fingrarna. Sådana rättelser som är införda i tryck, t.ex. på sista sidan, brukar vi föra in och då skriver vi en redigeringskommentar om detta. Dessa syns ju när man inspekterar historiken för sidan.
Förresten, i månadssammanställningar står editör-signaturer. Var kommer de ifr ån? Man knappar ju bara in e-postadressen. Skrivs
Det är mailadressen före "@"-tecknet som utgör signaturen. När jag fyller i lars@aronsson.se så syns "lars" i statistiken. Detta är inget fulländat system, och på sikt planerar vi att ersätta det med en riktig registrering och inloggning och cookies.
Hur kommer Unicode 8 att påverka detta? Inga (?) operativsystem och få ordbehandlare kan hantera Unicode.
Tyska och franska Wikipedia har så vitt jag vet inga problem med Unicode. Jag låter dem vara testpiloter, så kan vi lära av deras misstag.
2004-12-05 kl. 14.30 skrev Bengt-Olof Bjurman:
- Inför införandet av unicode
Främmande alfabeten borde inte translitteras då tex grekiska eta och epsilon blir båda e, = förstörelse av data. Märk istället de (ytterst sällsynt förekommande) orden med <grk>grekiska</grk> <heb>hebreiska</heb> <kyr>kyrilliska</kyr> <run>runor</run> etc
Finns inte detta redan i HTML: <Q lang="LANGUAGE"></Q> där LANGUAGE ett (standardiserat) signum, t.ex. no-nynorsk (nynorsk), i-sami-no (nordsamiska), en (engelska), fr (franska), o.s.v.
Jämför: http://www.w3.org/TR/html4/struct/dirlang.html#h-8.1
Nu har jag bara korrekturläst enstaka sidor men får man fråga varför policyn att korrekturläsa plain text först och inte gå direkt på modern HTML-XML-liknande textmärkning? Nordisk familjebok kunde ha en egen DTD-fil med ett schema typiskt för uppslagsverk. Det kanske t.o.m. finns färdiga scheman?
Märkningar på språket, nummer, o.s.v. är bra om texten ska pratas upp. Det är enkla märkningar (som t.o.m. finns i HTML) och om det finns personer som vill märka på detta sättet tycker jag inte det borde finnas motsättningar. Kan inte denna märkning samexistera med plain-text korrigering? Om inte sådana märkningar finns kommer ju Runeberg att negligera en viss publik, t.ex. synskadade.
- Märkning av sakfel.
Att rätta till sakfel i texten motsätter jag mig. (Kan man inte säga att detta har gjorts på de flesta historiska urkunderna som finns idag?) Men jag tror han menar att lägga till skolier, d.v.s. saker som inte förändrar textens ursprungliga form.
Bara mina synpunkter. :-) Roger