Dette er et lidt nørdet indlæg for mange, men ikke desto mindre et tilbagevendende problem for flere af dem, der kontakter mig pr. e-mail. Desuden har det, så vidt jeg husker, også været vendt i forumet, så her kommer en lille tale om UTF-8 vs. ISO-8859-1. Der er både forsvarstale og løsningsforslag, så læs blot videre.
UTF-8 er standard på alle WordPress-blogs, og den danske oversættelsesfil bliver kun oversat i UTF-8. Af en grund. Fire, faktisk. Men der er stadig nogle, der af uransagelige årsager især insisterer på at bruge ISO-8859-1. En del af dem, der vælger det, gør det af den simple årsag, at de inkluderer en blog på en side, der allerede er kodet i ISO-8859-1. Dem, der installerer en stå-alene-WordPress-blog og manuelt går ind og retter til ISO-8859-1 er ganske givet bare udenfor web-logisk rækkevidde. Arrrhhhh, ok. Men det er virkelig ikke den bedste løsning.
- Resten af WordPress er kodet i UTF-8
WordPress-kildekoden er kastet ind i (hovedsageligt) php-filer, der er kodet som UTF-8. At lave en oversættelsesfil som andet (dvs. ISO-8859-1 virker meget ulogisk. At bruge entities er derfor eneste logiske alternativ. - Entities gør teksten sværere at læse for oversætteren og skaber derfor større risiko for fejloversættelser.
Når vi som oversættere skal skrive de danske sætninger, bliver det lynhurtigt uoverskueligt at læse korrektur på teksterne, hvis der inkluderes entities. Det kunne eksempelvis give følgende oversætelse: - Entities bliver ikke læst rigtigt i e-mails.
Hvis man bruger entities i oversætelsesfilerne, kommer de til at stå i de e-mails, der bliver sendt ud fra bloggen. Både til administrator og brugere. Det er selvfølgelig på ingen måde hensigtsmæssigt. Kunne man kode de tekststrange, der sendes ud pr. e-mail som UTF-8 og resten af oversættelsesfilen med entities? Ja, det kunne man måske godt. - Oversættelser af plugins og temaer er ofte UTF-8
Når en eller anden Yderst Venlig Person sætter sig ned og oversætter et tema eller et plugin, som ikke er klargjort til oversættelse, finder obversættelsen sted i kildekoden. Det kan ikke forlanges af disse Yderst Venlige Personer, at de sætter sig ind i tegnsæt, entiteter osv. og at de ikke falder i korrekturfælden i #2.
Alt i alt kan jeg kun sige: Brug nu for fandengalemig og krafthelvede bare UTF-8!
Nååååå nej, der var jo disse hersens integreringsmennesker, som på det nærmeste er tvunget ud i at lave bloggen til ISO-8859-1 (eller i meget få tilfælde et andet tegnsæt). Dem vil vi også gerne have til at bruge WordPress. På dansk, vel at mærke. Så er det godt, vi har en entrepenant finsk ven i Kimmo Suominen. Han har nemlig brygget et par plugins, som vi forsøger at få inkluderet i selve WordPress-koden. Men det har vist lange udsigter. Især fordi de kræver, at din host kører modulet iconv, hvis de bruger PHP4 (det er standard i PHP5).
Det ene plugin, som er det, der er klart mest relevant for de fleste, er Character Set Conversions. Og ja, det gør, hvad det siger. Laver UTF-8-tegnene om til det tegnsæt, du bruger. Det andet plugin, som kan blive nødvendigt for nogle få, er Multibyte Mail, som praktisk taget gør det samme for dine WordPress-e-mails, som Character Set Conversions gør for selve bloggen.
Moralen i denne historie, spørger du? Det skal jeg sige dig. Brug UTF-8, hvis du har mulighed for det. Hvis du ikke har det, er der stadig ingen grund til at finde et andet værktøj. Det er de uanede mængder af plugins og temaer, der gør WordPress til det klart bedste blog- og minicms-værktøj på markedet i øjeblikket. Det er bare om at komme i gang.