Översättningsprojekt

Häromdagen nämnde jag att jag har varit involverad i den svenska översättningen av Drupal. Detta har lett mig in på ett potentiellt Drupal projekt som har som mål att automatiskt kunna identifiera felaktiga översättningar.

En översättning är i princip bara ett par textsnuttar som är kopplade till varandra. Den ena är i originalspråket (vanligtvis engelska) och den andra är på svenska. Drupal använder sig av ett översättningsbibliotek som heter Gettext som sparar dessa strängar på ett mycket enkelt och bekvämt sätt i .po-filer (och .pot-filer). Genom plocka in dessa textsnuttar och för varje översättning jämföra dessa så finns det en hel del småfel som kan identifieras redan innan de skickas in till den centrala kodbasen på Drupal.org. Kalla det automatisk testing av översättning, om man så vill.

Projektet ligger nu på planeringsstadiet och här diskuterar den svenska gruppen vad för typ av misstag som modulen/programmet skulle kunna identifiera.

Man vill ju helst inte göra dubbeljobb, och det låter som att testing av översättning redan är på ingång, frågan är just var på Drupal.org jag kan finna det/de projekt(en) som eventuellt redan har kod skriven för liknande saker. Man vill ju helst att det ska vara modulärt och utbyggbart - medans svenska och danska gruppen säkert har i stort sett samma krav på felöversättningar så kan det skilja sig radikalt i jämförelse med t.ex. arabiska. Av den anledningen ser jag typ att projektet implementerar en svit av tester och att olika språk därefter skapar en profil, som är en urval av dessa tester för deras språk.

Det ska bli intressant att se hur det här går.

Digitalt liftande

Förra veckan presenterade en vän en kul affärsidé för mig. Han bjöd in mig i projektet. Men som många idéer var denna redan tagen...och som sådan så kan jag nu berätta vad idén gick ut på.

Genom att åka tillsammans i bilar så sparar man både pengar, trafik och miljön. Detta var grundtanken i projektet. Men det är inte alltid man har passagerare i sin nära omgivning (vänner, familj etc.).

Min väns lösning på problemet var en webbportal där passagerare och förare kunde finna varandra. Passagerare och förare skrev in vart de vill/skulle och sedan matchade hemsidan dessa med varandra.

Enkelt, kul och så gjorde man någonting bättre för världen. Ett sorts digitalt liftande kan man säga. Vi gick igång på idéen och jag har vänt och vridigt på idéen under den senaste veckan och utgått från att ingen annan gjort det eftersom min vän har försökt finna något liknande på nätet under ett halvår.

MEN! Idag damp det ner ett mejl. PickupPal.com är en exakt replika av vad vi hade tänkt oss. Någorlunda snygg, enkel och smidig. De har testat den affärsidé vi tidigare hade med att ta provision utan att lyckas men numera övergått till att bara tjäna pengar på reklam, något som vi också hade diskuterat.

Jag har ett konto nu och ska nu testa tjänsten. Den kommande helgen planerar jag, och Julie som jag har på besök, att fara till Stockholm. Efter att ha lagt in att vi vill lifta till Stockholm så har två förare blivit kontaktade. Ska bli spännande att se vad de har att säga.

Tillbaka till planeringsstadiet,

Jens

Produkter av FRA-lagen

Efter att FRA-laget klubbades igenom häromdagen så har Alliansen fått en del hårda smällar:

1) Finlands kommunikationsminister överväger att varna finnar att deras kommunikation kan avlyssnas när de talar över telefon och internettrafik med Sverige. Problematiskt är det i Finland också då en stor del av deras internationella internettrafik går via bottenviken och passerar alltså Sveriges gränser.

Andra internationella aktörer har redan före omröstningen igår kritiserat lagförslaget. I Mars gick Google ut och sa att de inte tänker investera i några datacentraler i Sverige om lagen träder i kraft. Andra stora aktörer har också visat kalla handen mot Sverige efter lagen.

2) Många arga mail har inkommit till regeringen. Enligt DN sa registratorn idag att de "formligen blivit mejlbombade". Lycka till med att svara på de mailen. I samma veva vill jag också nämna att den mailtråd som jag har blivit insvept i (se föregående blogginlägg) fortfarande pågår. Många intressanta och välskrivna inlägg är det där.

3) DN har dessutom publicerat en artikel om hur man enkelt kringår att bli avlyssnad av FRA. Äntligen har en del av det material som jag velat göra allmänheten mer uppmärksam på nått den breda massmedian. E-post kan avlyssnas lätt! Det finns även program för att göra ens surfande anonymt med mera.

Synd är dock att DN inte har fokuserat mer på gratisversionen av GNU Privacy Guard som kan användas för att kryptera mail och är gratis. Jag har funderat länge på att skriva ett litet informationsmaterial om hur det fungerar. Alternativt en bok. Kanske det är dags nu?

Även NyTeknik tycks ha publicerat en artikel om hur man kringår FRA:s avlyssningar.

Dessa två artiklar visar hur oerhört lätt det är att kringå FRA:s spaning och säger på samma gång väldigt mycket om hur mycket mer lagförslaget går emot demokrati och inte gör någon skillnad rent tekniskt i övrigt - vill en terrorist inte bli avlyssnad så finns det en uppsjö med programvaror gratis på nätet för att kryptera sin kommunikation.

Drupal och 17 fördelar

Att programmera välstrukturerade, snygga, stora dynamiska webbplatser är inte enkelt och jag börjar komma till slutsatsen att det kanske inte är så smart att återuppfinna hjulet varje gång. Efter att ha djupstuderat ett fritt (CMS) system som heter Drupal har jag kommit till insikt att advancerade sajter kan skapas på ett bättre sätt.

Webbplatser bygger på en uppsjö av olika tekniker för att fungera. När de första webbsidan publicerades 1991 av Tim Berners-Lee så bestod varje webbsida av vanlig text, fylla med en del kodsnuttar som berättade exempelvis var fetstil började och slutade. Detta blev vad som skulle kallas HTML (HyperText Markup Language). Fyra år senare kom JavaScript, den första tekniken som kunde få statiska sidor på Internet att vara lite mer levande, och däremellan hade redan dynamisk generering av webbsidor uppkommit (t.ex. aftonbladet). Men som vi alla vet så har utvecklingen gått snabbare och snabbare och idag finns det en uppsjö av tekniker och metoder för att få den professionella funktionalitet/design som så många webbplatser har: HTML, XML, XHTML, CSS, JavaScript, Apache/PHP/SQL, ASP(.NET), Python, JSP (Java), Ruby on Rails med flera...

Precis som glaset kan vara både halvfyllt och halvtomt så ger alla dessa tekniker både fantastiska möjligheter men saknar samtidigt ett klart och tydligt sätt hur de ska interagera på ett flexibelt sätt. Som en webbutvecklare för större webbplatser så frågar man sig ständigt frågor såsom:

• Hur kan jag konstruera en webbplats där jag över en dag kan ändra hur den ser ut?
• Hur konstruerar jag ett smidigt och snabbt system för hur behörigheter på webbplatsen fungerar?
• Vilket typ av innehåll ska min webbplats innehålla? Hur strukturerar jag det i databasen?
• Hur implementerar jag en flerspråkig webbplats?
• Hur implementerar jag sökmotor för hela webbplatsen?
  

När jag under ett års tid satt jag som förtroendevald webmaster åt Helsingkrona nation i Lund så ställdes frågor som dessa på prov. Arbetet bestod i att underhålla och utveckla helsingkrona.se. i samarbete med andra förmän och utskott.

Helsingkrona.se är en helt hemsnickrad komplex webbsajt som erbjuder användare med en viss behörighet att redigera alla artiklar och publicera både interna och externa nyheter. Utöver detta så har webbplatsen ett community som erbjuder funktioner á la (simplifierad) Facebook/Lunarstorm; bildgalleri, privata meddelanden, forum med mera.

Viktigt att förstå är att jag här inte bara talar om hur man impmenterar funktioner i listan, över utan även hur man strukturar en webbplats på ett så sätt att ny tung funktionalitet såsom lägga till ett nytt språk, en ny design, flytta webbplatsen, skins - arbeten som kan bli oerhört tunga om man inte har haft det i åtanke redan från första början. Kalla det vad ni vill - flexivilitet, modularitet - kärt barn har många namn.

Att skriva ett flexibelt hemsidesystem är oerhört svårt. Hur vet man hur stor en webbplats kommer att bli? Ska man räkna med att sidan skall översättas till spanska, engelska och italienska redan från första dagen? Vi som utvecklade Helsingkronas hemsida insåg att webbplatsens kod behövdes omarbetas och arbetar i själva verket för tillfället med att städa upp och strukturera upp.

Men i samband med att jag har tre andra större webbplatsprojekt inom en nära framtid så har jag under de senaste veckorna gjort en djupdykning i CMS-djungeln. Jag har fokuserat på Drupal då många forum och äldre blogginlägg tycktes visa på att denna CMS visserligen hade en lite högre inlärningströskel än många andra, men var oerhört kraftfullt.

Förkortningen CMS står för Content Management System och är precis vad som har implementerats på Helsingkrona.se. Ett CMS kan sägas vara en webbpubliceringsplattform - ett system som erbjuder enkel redigering av webbsidan via en webbläsare. Vissa kommer även med funktioner för att ha ett community.

Det finns oerhört många att välja bland - vissa är gratis, andra fria och en del behöver man betala töntigt stora summor för. Drupal är öppen källkod, vilket ger många fördelar gentemot slutna; Över hundra utvecklare sitter världen över och ser över all kod som skrivs till plattformen. Detta gör att koden inte kan tappa fokus på vara lättläst eller sakna flexibilitet för att passa många behov. Det ger såklart även en boost i hur säker systemet kan anses. 200 ögon är bättre än sex.

Att projektet är kollaborativt ger även en annan boost - Drupals dokumentation är alldelles fantastisk. Det finns guider för allt, och skriftliga beskrivningar över API:er. Skulle dokumentation av någon anledning saknas så finns hjälp alltid nära till hands via dess stora användarbas på groups.drupal.org.

Vi har tio sidors tunn dokumentation av Helsingkronas hemsida.

För att hålla min stora nya fascination för Drupal kort så presenterar jag här en lista över alla de fantastiska fördelar som jag ser med det:

1. Öppen källkod.
2. Stor användarbas med aktiva forum och diskussionsgrupper.
3. Snygg, väldokumenterad kod.
4. Ett mycket snillrikt system uppbyggt av moduler som starkt uppmuntrar ny kod att delas upp så att man vet var man hittar den. Möjlighet att stänga av och sätta på moduler finns.
   
5. Många färdigskrivna moduler
   
6. Stöd för sökmotorvänliga adresser.
7. Stöd för mallar/skins som gör att man kan dela upp användargränssnitt och bibliotek.
8. Stöd för webbplatser på flera språk.
1. Automatisk igenkänning av vilket språk en besökare har på sin dator.
2. Läckra användargränssnitt för att se vilka sidor som behöver uppdatera sin översättning.
3. Möjlighet att ladda ner alla (~1600!) vanliga ord och uttryck från drupal.org samt bidra till gemenskapen om man har uppdaterat översättningarna till det bättre.
9. Tydligt administrationsgränssnitt.
10. Läckert API för att hantera formulärdata på ett flexibelt och mycket mer säkert sätt.
11. Möjlighet att kategorisera nyheter och sidor på sin webbplats och filtrera efter detta.
12. Communityfunktioner så det ryker om det:
1. Vänlistor
2. Skicka meddelanden mellan användare
3. Skriva böcker och artiklar tillsammans
4. Forum
5. Delta/Skapa i grupper
6. Bloggar
   
13. Fantastisk behörighetssystem för att dela in användare i grupper såsom författare, webmaster etc. Man kan t.ex. ställa in att vissa användare bara får redigera vissa artiklar/böcker.
14. Snabbt (har överlevt en slashdottning) - har inbyggt cache i systemet.
15. Mycket snygg och flexibel lösning på hur man administrerar menyer på en sajt.
16. Hjälpfunktioner för AJAX-funktionalitet.
17. Möjlighet att översätta JavaScriptkod till flera språk.

...och sist men inte minst så har Drupal tänkt på så mycket att avancerad funktionalitet är lätt att implementera. Det var det den här bloggposten egentligen handlade om.

Drupal är fantastiskt och jag ser fram emot att jobba i det. Version 6.0 kom ut för ett par veckor sedan och deras moduler håller på att upgraderas till den nya versionen. Jag har hjälpt till lite med översättnignen till Svenska.

Urinoartankar i Manhattan

För många år sedan läste jag en artikel ur tidningen NyTeknik. Artikeln handlade om ett nytt material som hade utvecklats med hjälp av nanoteknik (en tvärvetenskap som i princip handlar om att kunna placera atomer i relation till varandra exakt som man vill). Materialet bestod av extremt små taggar gjorda av några få atomer per tagg.

Det intressanta med det nyutvecklade materialet var att dessa pyttesmå taggar gjorde att vattendroppar som träffade materialet inte stänkte - dropparna fångades upp mellan taggarna. Och tillämpningarna på detta? Artikeln nämnde bland annat att materialet kanske kunde användas i pissoarer och på så sätt minska stänket.

Urinstänk är ju varken kul för båda folk med eller utan snorre, och värst är pissoarstänk speciellt om man har barfotasandaler eller shorts (läs: Jens). Artikeln i NyTeknik fick mig att börja tänka och då jag läste den under min första tid i Lund så var pissoaranvändningen stor, heh. Varje gång jag stod vid en urinoar funderade jag; Hur kan man konstruera en urinoar som inte stänker? Och dessa tankar har tills denna dag aldrig lämnat mitt huvud.

Min tes som jag driver är att en stråle stänker som mest när den riktas vinkelrätt mot en yta. Ett spännande projekt hade varit att statistiskt visa att så är fallet (givet en bra definition på "stänk", såklart). Jag har flera följdfrågor: Hur kan man mäta stänk på golvet på något sätt? Finns det modeller för vätskestänk mot en yta? Görs liknande forskning av företag som konstruerar pissoarer idag?

Om jag själv hade haft tid och pengar hade jag förmodligen gjort stänkmätningar genom att lägga ut en vit duk under pissoaren och fukta den med någon typ av indikator som byter färg vid reaktion med vatten. Relativ simpel bildanalys hade sedan kunnat ge ett värde på stänk som funktion av infallsvinkel på stålen.

Men finns det enklare empiriska tester man kan göra för att visa eller motbevisa min tes? Jag tycker det. När jag i shorts och/eller sandaler går går på herrtoaletten brukar jag placera min stråles träffpunkt i utkanten av urinoaren och på så sätt låta strålen träffa urinoarytan med en större vinkel mot dess normal*. Jag anser att stänket blir mindre än om jag placerar strålen rakt in mot urinoarytan. Är det någon som har en kommentar på detta?

Problemet med min teknik att placera träffpunkten på dagens urinoarer är att en stråle aldrig är helt solid. Ibland flyger små droppar i lite andra riktningar. Dessa splittrade droppar kan missa pissoaren helt och istället träffa vägen bredvid, vilket ju till viss del motsäger hela idéen att använda tekniken. Om denna tes visar sig vara riktig så skulle det leda till en ny typ av pissoarer som "fångar upp"* strålen i mitten av urinoaren på sådant sätt att stänket minimeras och samtidigt är inom ramen. Se bild här bredvid.

Innan jag avslutar det här blogginlägget så vill jag även nämna två andra saker:

Det första är den kända flugan som en del pissoarer har för att män skall placera sin träffpunkt där. Flugan är inte placerad på ett ställe som minimerar stänk, utan relativt centralt i pissoaren. Studier har visat att flugan dels hjälper till få användarna att träffa inom pissoarens ram snarare än utanför, men också att urinläckage minskar med 80% om män med detta problem tänker på flugan istället för att knäcka upp jylfen.

För det andra, om det visar sig att min test är felaktig så ser jag två sätt att lösa det irriterande stänket:

• Börja använda det materialet som nämndes i NyTeknik-artikeln.
• Skapa pissoarer som är djupare och har träffytan längre från användaren. Ibland när jag är ensam i en herrtoalett så tar jag några steg tillbaka och kör lite distansskytte - en någorlunda fungerande teknik så länge ingen kliver in på toaletten och tror att jag är tokig.

Detta blogginlägg skrevs till största del under min Manhattan vistelse med familjen, men avslutades under flygresa till Chicago från New York. Jag kommer nu att befinna mig i Chicago till den åttondo. Gott Nytt år på er!!!

---

* Med andra ord skulle stråle och yta är vid första kontakt vara närapå parallella.

Optimering av läsbarhet

I somras hade jag en sommaranställning i två och en halv månad med ett forskningsprojekt på Humanistlaboratoriet vid Lunds Universitet som lundabor finner nere i källaren på det nya Språk och Litteraturcentrum (SOL-centrum). Forskningsprojektet gick i korthet ut på att förbereda mätningar och analys av lästester från över 300 ekonomistudenter som skulle läsa en text på datorskärm i en kvart vardera. Experimentet skulle utföras under oktober månad nu i höst (2007).

Under utvecklingens gång stötte jag på många små problem och en av dessa gällde läsbarhet av texter på datorskärm under olika design ([1], [2], [3], [4], [1.5]). Jag gjorde lite bakgrundsundersökningar på Internet och fann mycket information gällande teckensnitt och utformning av dessa. Mer intressant var att avsaknaden av att undersöka hur olika färger fungerade tillsammans. Min chef Kenneth, som hade lite koll på området, trodde inte att det hade gjorts mycket undersökningar inom området.

Vissa sidor menade att det var viktigt att kontrasten mellan förgrund och bakgrund var viktig (duh!), men var fanns undersökningarna om olika färgkombinationer?

A. L. Hill (1997) hade visserligen en undersökning som många uppenbarligen verkar hänvisa till (då den dyker upp högt upp i sökning på Google), men jag tyckte att den vacklar i sin metod att välja ut de färger som analyseras för vidare analys. Att bara välja ut 6 stycken bakgrunds-/förgrundsfärger är en spott i havet. En dator representerar vanligtvis en färg i RGB (rött, grönt, blått) baspar. Rent teoretiskt ligger i de flesta fall varje färgstyrka i intervallet 0-255, vilket ger 256^3=16 777 216 olika färgkombinationer. Rent teoretiskt (kombinatoriskt) så finns det alltså (256^3)^2=256^6=281 474 976 710 656 ~= 2.8*10^14 olika bakgrunds-/förgrundspar. Hur kan man då välja ut 6 kombinationer av detta?

Motargumentetet är att ett mänskligt öga inte kan se någon större skillnad mellan RGB(0,0,0)/RGB(0,0,0) och RGB(0,0,0)/RGB(0,0,1) - visst, men tänk er då att intervallet 0-255 istället delas in i 16 distinkt olika färger. Detta skulle ge 16^6 = 16 777 216 olika kombinationer av förgrunds-/bakgrundsfärger - i jämförelse med 6 stycken!

Idag fick jag en liten idé som jag skulle kunna tänka mig att spinna vidare på. Det är ju rent praktiskt omöjligt att göra en undersökning som undersöker läsbarheten för alla dessa kombinationer av färger, men problemet skulle faktiskt kunna ses som ett optimeringsproblem: Givet färger så vill man optimera läsbarhet.

Om man gör antagandet att läsbarhet är proportionell mot läshastighet (och att försökspersonen inte slutar läsa texten) så skulle man kunna implementera en hemsida som beroende på hur snabbt en läsare läser en artikel kan optimera färgkombinationerna. Idag har många sidor sina artiklar uppdelade på flera sidor, och det är precis den funktionaliteten som man skulle kunna utnyttja.

Att läsare manuellt ger respons på läsbarhet i all ära, men vem orkar göra det?

Vilken optimeringsalgoritm man skulle kunna utnyttja är inte trivialt, men jag kan tänka mig att Simulated Annealing skulle kunna vara en mycket välfungerande algoritm för projektet, eller varför inte en evolutionär algoritm?

Det intressanta är att dessa idéer på ett sätt ligger i linje med två av de kurser jag läser nu. Datorgrafikkursen behandlar nu ytligt perception och hur ögat och hjärnan behandlar synintryck, såsom färger. Min matematikkurs, Matematisk Modellering, behandlar ytligt olika modeller för optimering - såsom just de ovannämnda. Modelleringskursen kommer att innehålla ett större projekt, är det detta jag vill göra?

Så vad krävs för att projektet ska gå i hamn?

• En välbesökt sida (nej, min blogg är inte så välbesökt :-) - jag har i medel 2 besök per dag)
• En sida med ordentlig databas.
• En duktig programmerare som vill leka med parametrarna i den "simulerade stelningen". Givetvis kan färgerna inte slumpas fram helt till en början, utan något krav får nog finnas på exempelvis kontrast mellan färgerna.
• Som alltid...tid och vilja.
  

Referenser:

1. Readability Of Websites With Various Foreground/Background Color Combinations, Font Types And Word Styles, 1997, A. L. Hill (se också här)
   
2. The Five-Finger Readability Rule, 12/9-07, K. Stout
3. Wikipedia - Readability (in writing), 12/9-07
4. Readability, 12/9-07, www.webdesignfromscratch.com