En arabisk bokningssajt är inte en översättning
En resebyrå i Jeddah slår på arabiskan, tittar på startsidan och bestämmer att jobbet är klart. Två veckor senare vidarebefordrar en kund en prislänk till sin syster på WhatsApp, och den kommer fram som en vägg av procenttecken. En annan ringer för att totalsumman dök upp på vad hon anser vara fel sida av priset. En tredje bokar Riyadh–Dubai fel dag, för att datumväljaren började veckan på måndag. Inget av det är en översättningsbugg. En arabisk bokningssajt är en layout, ett sifferssystem och ett URL-schema innan den är en uppsättning strängar — och strängarna görs först, eftersom de är den del som syns på en skärmdump.
För en svensk byrå är det inte exotiskt. I samma stund som du säljer mot Gulfen, betjänar arabisktalande kunder eller driver en storefront åt en partner i Emiraten gäller precis samma lista. Så här ser det ut i praktiken, ungefär i den ordning byråer springer in i det.
RTL är ett layoutbeslut, inte en textriktning
Att sätta dir="rtl" speglar sidan. Navigationen flyttar till höger, filterlisten till vänster, styckena högerjusteras. Den delen är nästan gratis. Det dyra är allt som inte får speglas.
Avgångstider speglas inte: 07:45 är 07:45. En ruttrad som läses DXB till CAI måste fortfarande läsas som en rutt i den ordningen inne i ett högerläst stycke, eftersom avreseflygplatsen är avreseflygplatsen oavsett åt vilket håll meningen springer. Flygbolagskoder, PNR och e-ticketnummer är latinska strängar nedsläppta i arabiska meningar, och är de inte isolerade sorterar webbläsarens bidirektionella algoritm om skiljetecknen runt dem — en record locator följd av punkt kan renderas med punkten i fel ände, vilket för kunden ser ut som ett stavfel i den egna bokningsreferensen. Din logotyp speglas inte. En play-triangel speglas inte. En bakåtpil gör det.
Sedan kommer sakerna ingen listar förrän en kund nämner en av dem: ordningen mellan valutasymbol och siffra, stegindikatorn genom bokningstratten, säteskartan, åt vilket håll en karusell rör sig, vilken sida av en träffrad flygbolagets logotyp sitter på, och från vilken kant en bred pristabell scrollar. Varje sådan sak är ett beslut. Ingen av dem är en flagga man sätter.
Siffror, datum och kalendern kunden faktiskt håller i
Arabiska skrivs med två sifferuppsättningar som båda är i vanligt bruk, och resor är fulla av siffror: priser, tider, restider, bagagegränser, kortfält, OTP-koder. Vilken uppsättning din marknad läser är en fråga att besvara en gång, med dina egna kunder, och sedan tillämpa utan undantag. Det synliga misslyckandet är inte att välja den mindre vanliga. Det är att blanda dem — ett pris i den ena och en avgångstid i den andra på samma träffkort — vilket läses som en halvfärdig sajt.
Datum bär fler antaganden än siffror gör. En vecka som börjar på måndag är fel för en kund vars vecka börjar på söndag, och en kalender som startar på fel dag orsakar exakt en sorts misstag: en bokning en kolumn fel. En kund som planerar umrah räknar i en hijri-månad, inte en gregoriansk, och att visa hijri-datumet bredvid det gregorianska i datumväljaren och på resplanen kostar ingenting och sparar ett telefonsamtal. Att visa det överallt, på en affärsresa till Frankfurt, är brus.
Vad en arabisk bokningssajt måste få rätt
Glappet mellan en översatt och en lokaliserad sajt är yta för yta, inte globalt. Det här är listan värd att bråka med utvecklaren om:
| Yta | Bara översatt | Faktiskt lokaliserat |
|---|---|---|
| Passagerarnamn | Fältetiketter på arabiska | Inmatning med latinska bokstäver, märkt som det står i passet, eftersom det är namnet flygbolaget har i sin PNR |
| Datum | Månadsnamn på arabiska | Läsarens första veckodag, läsarens siffror, hijri bredvid gregorianskt där resan kräver det |
| Pengar | Valutanamnet översatt | Marknadens standardvaluta, och listan du faktiskt säljer i |
| Telefon och OTP | Etiketter på arabiska | Marknadens landskod förvald, latinska siffror i fältet, koden läsbar vid en blick |
| Flygplatser och städer | Namn på arabiska | Arabiskt namn med den latinska IATA-koden kvar synlig, för en underagent skriver DXB och en resenär läser arabiska |
| URL:er | Titeln översatt | En slugpolicy per språk, bestämd en gång |
| Typsnitt | Systemets arabiska reservsnitt | Ett arabiskt snitt valt för sina siffror och för små storlekar, inte ett latinskt typsnitt med arabiska inlånad bakom |
| Kontakt | En översatt kontaktsida | Ett nummer en kund på den marknaden faktiskt kan ringa, under timmar då hen är vaken |
Namnraden är den som kostar riktiga pengar, och den är oftast fel. En resenär skriver sitt namn på arabiska för att formuläret bjöd in till det, biljetten utfärdas mot den strängen, och den matchar inte passet flygbolaget kontrollerar. Allt nedströms — ombokningen, diskussionen, återbetalningen — landar hos dig och inte hos transportören.
Typsnittsraden är billigare än den ser ut. På den här plattformen är temat, inklusive typsnitt, färger och logotyp, utbytbart från adminpanelen utan omdeploy, så att prova ett annat arabiskt snitt mot din egen pristabell är en eftermiddag snarare än en release. Valutaraden är ett eget ämne; vi gick igenom den i bokningssajt med flera valutor och var marginalen läcker.
Slugar, och vad som överlever en WhatsApp-klistring
En arabisk slug renderas vackert i adressfältet och består av de ord folk faktiskt skriver i en sökruta. Kopierad in i ett vanligt textfält procentkodas den och sväller flera gånger om, och det din kund vidarebefordrar ser ut som maskinutskrift. En latinsk translitterering klistras rent och är oläsbar för alla — den matchar ingenting en arabisk läsare söker på och ingenting en engelsk gör.
Dela beslutet efter vad URL:en är till för. En innehållssida lever eller dör på sök, så ge den sluggen i eget skriftsystem; den kodade formen dyker bara upp när någon kopierar den, och sidan den landar på är rätt ändå. En bokningsdeeplänk — en träff, ett hållet pris, en offert till en underagent — kommer ändå aldrig bli snygg, eftersom den bär datum och antal resenärer i query-strängen. Ge den en kort länk och låt den förbli kort.
Regeln under båda: en kanonisk URL per sida och språk. Att publicera samma artikel på en arabisk slug och en translittererad delar allt den sidan förtjänar mellan två adresser och lämnar dig att underhålla båda.
hreflang, annars konkurrerar din arabiska sida med din engelska
Två språkversioner av en sida är inte två sidor. Om en crawler inte kan avgöra det är det vanligaste utfallet inte ett straff — utan att en version väljs och den andra behandlas som near-duplicate och tyst faller bort.
Fyra saker håller isär dem. Varje språk behöver sin egen URL, vilket utesluter en adress med en JavaScript-växlare. Varje version listar alla språk inklusive sig själv, eftersom en uppsättning som inte pekar tillbaka på sig själv kasseras i sin helhet. Varje sidas canonical pekar på sig själv, inte på det engelska originalet — arabiska sidor som kanoniseras mot engelska är det snabbaste sättet att inte ha några arabiska sidor indexerade alls. Och x-default går dit du vill att en läsare utan träff ska landa.
Motstå att dela upp i ar-AE och ar-SA om inte de sidorna verkligen skiljer sig — annan valuta, annat telefonnummer, annat utbud. Två regionala varianter av identisk text är två sidor som slåss om samma sökning, båda med ditt namn på.
Vad det kostar dig när det är fel
Avhoppet sker inte på startsidan. Det sker på passageraruppgifterna, som är det dyraste stället i tratten att tappa någon på: kunden har redan sökt, valt, sett priset och accepterat det, och du har redan betalat för sökningen som förde hen dit.
Resten av kostnaden är tystare. Varje förvirrad uppringare är en personalminut du gick online för att spara. Varje namnkrock är en ombokning och en kund som skyller på dig snarare än på flygbolaget. Och en arabisk sida som aldrig indexeras är en artikel du betalat för som ingen kan hitta — den enda sortens misslyckande som inte genererar några klagomål alls, vilket är varför den kan pågå i ett år.
Var du börjar
Om arabiska är din andra marknad är arbetet en efterhandsbygge och tabellen ovan din punchlist. Är det din första vänder ordningen: välj sifferuppsättning och arabiskt snitt före färgschemat, bygg passagerarformuläret mot ett riktigt pass, och behandla engelskan som översättningen.
Hur som helst är det billigaste testet en riktig storefront framför en riktig kund. Guiden på skapa en resesajt provisionerar en varumärkt sajt på en plattformssubdomän från formuläret själv och frågar inte efter kort; storefronten går i 40 språk, arabiska, persiska, hebreiska och urdu bland dem, med egen domän kopplingsbar senare. Om du fortfarande överväger att bygga motorn själv är den frågan genomgången här — men gör det på arabiska innan du bestämmer dig, för RTL-arbetet är den del interna estimat lämnar ute.