Idé för flexiblare språkhantering i Drupal

Drupal är för det mesta ett alldeles underbart ramverk att utveckla i men ingenting är perfekt och det finns ett par brister som man återkommande stöter på.

En sådan brist som jag har reflekterat mycket över den senaste tiden är Drupals språkstöd. För oss svenskar är en flerspråkig webbplats väldigt vanligt. Och även om kunden bara vill ha en svensk sida så vet vi av erfarenhet att den där engelska versionen mycket väl kan komma i en framtida beställning. Därför har vi alltid flerspråksstöd i åtanke när vi bygger nya webbplatser.

Problem

Det finns ett flertal brister med t()-funktionen, som Gábor Hojtsy radar upp i sin post Drupal's multilingual problem - why t() is the wrong answer, och en av dem är att t()-funktionen vill ha allting i engelska som källa. En svensk översättning blir tätt kopplat till en specifik engelsk sträng. Önskar kunden ändra en hårdkodad engelsk källtext innebär det både att de behöver kontakta oss för att ändra i koden samt att den svenska översättningen (och andra eventuella språk) behöver matas in på nytt.

Lösningen?

En punkt som Hojtsy nämner i sitt "ideala system" är att man inför "string identifiers". Detta innebär att istället för att ha en engelsk text som källa för översättning har man en sträng-identifierare. Denna variant finns i många andra system.

Kreativ Fredag
Ett återkommande tillfälle på Kodamera där medarbetarna under en arbetsdag får möjlighet att på egen hand eller i grupp fördjupa sig i branschrelaterade idéer.

När jag läste Hojtsys inlägg väcktes en tanke hos mig om hur man redan idag kan åstadkomma en sådan lösning med ganska enkla medel. På en av våra Kreativa Fredagar här på kontoret valde jag att testa mitt koncept för att se om det för det första ens fungerar och om det finns några stora nackdelar eller brister.

I praktiken

Vad jag ville åstadkomma är alltså att jag i kod vill definiera en sträng med en identifierare, se jämförelsen med tidigare metod nedan:

// Normala sättet, t()-funktionen tar en engelsk sträng och gör
// tillgänglig för översättning till andra språk
t('This is an english hardcoded description')
// Mitt koncept, t()-funktionen tar en godtycklig string identifier och gör
//  tillgänglig för alla språk, inkl. engelska
t('CUSTOM_MODULE_DESCRIPTION')

Här stöter man på det första problemet. t()-funktionen förutsätter att texten man skickar in är på engelska, vilket betyder att Drupal tror att min string identifier är en engelsk sträng. Hur ska man då kunna översätta strängen till engelska? Vad vi behöver är ett engelskt presentationsspråk, utöver det engelska som utgör Drupals grundspråk (och således t()-funktionens). Detta löses genom att skapa ett custom språk.

En tanke som uppstod är hur strängar från core- och contrib-moduler sköter ett custom språk, men eftersom det inte finns en översättning till mitt custom engelska så används den ursprungliga strängen, vilket är just engelska.

På bilden nedan ser vi hur det kan se ut i gränssnittet när vi har våra strängar på plats. Vi ser snabbt om det saknas en översättning någonstans och som en liten bonus testar vi vår design mot långa strängar som man ibland missar att testa.

Man märker snabbt att det är väldigt viktigt att namnge sina strängar på ett tydligt och bra sätt så att man lätt vet vad det är för strängar när man skall översätta dem. Rimligtvis bör man prefixa med antingen modul- / temanamn eller webbplatsens titel. För att göra det lätt för kunden att söka upp översättningar så är kanske webbplatsens titel att föredra.

Fördelar

Vad tjänar vi då på att ha dessa krångliga identifierare i vår kod?

• Som utvecklare behöver vi inte ha en engelsk text redo att populeras i kod
• Identifierarna är konstanta, man kan ändra engelska texten utan att tappa alla andra översättningar
• Som kund behöver man inte blanda in en utvecklare för att ändra en engelsk text som är definierad i kod
• Det blir lätt att söka upp strängar i Drupals översättningsgränssnitt om man prefixar identifierarna med t.ex. webbplatsens namn
• Man upptäcker lätt om en sträng i gränssnittet inte är översatt

 

Nackdelar

Det finns uppenbarligen ett par fördelar med det här konceptet men tyvärr finns det även ett par nackdelar som är värda att nämnas:

• Det går emot hur resten av Drupal fungerar; det här lämpar sig endast för egna teman och moduler som är interna
• Man drar inte nytta av översättningar från Drupals community
• Fält-titlar och beskrivningar definieras inte med engelska som t()-funktionen utan använder det konfigurerade standardspråket som källa.
• Views title definieras precis som fält ovan i standardspråket (lustigt nog fungerar Header, Footer och Empty-texter utan problem)
• Kan uppfattas som rörigt för kund då sträng-identifierare blandas med det gamla vanliga sättet när man översätter

 

Slutsats

Efter att ha testat det här under en dag står det klart att det är ett väldigt intressant koncept och jag önskar att Drupal valde att gå åt det här hållet i core. Det är tyvärr inget som diskuterats för Drupal 8 så det lär dröja. Min lösning är lite utav en "ful" workaround för att få till det i dagsläget som endast bör användas för interna projekt där koden inte kommer att delas med Drupals community.

Fördelarna är grymma och nackdelarna är egentligen inga stora hinder men vi kommer att behöva diskutera det vidare internt innan vi kan avgöra om det är något vi vill testa i ett skarpt projekt.