En arabisk bookingside er ikke en oversættelse

Et rejsebureau i Jeddah slår arabisk til, kigger på forsiden og beslutter, at opgaven er løst. To uger senere videresender en kunde et prislink til sin søster på WhatsApp, og det ankommer som en mur af procenttegn. En anden ringer, fordi totalen dukkede op på den side af prisen, hun regner for den forkerte. En tredje booker Riyadh–Dubai på den forkerte dag, fordi kalenderen begyndte ugen på en mandag. Ingen af delene er en oversættelsesfejl. En arabisk bookingside er et layout, et talsystem og et URL-skema, før den er en samling strenge — og strengene bliver lavet først, fordi de er den del, man kan se på et skærmbillede.

For et dansk bureau er det ikke eksotisk. I det øjeblik du sælger mod Golfen, betjener arabisktalende kunder eller driver en storefront for en partner i Emiraterne, gælder nøjagtig samme liste. Her er det, der reelt ændrer sig, nogenlunde i den rækkefølge bureauer støder ind i det.

RTL er en layoutbeslutning, ikke en tekstretning

At sætte dir="rtl" spejler siden. Navigationen flytter til højre, filterpanelet til venstre, afsnittene højrestilles. Den del er nærmest gratis. Det dyre er alt det, der ikke må spejles.

Afgangstider spejles ikke: 07:45 er 07:45. En rutestribe, der læses DXB til CAI, skal stadig læses som en rute i den rækkefølge inde i et højrelæst afsnit, for afgangslufthavnen er afgangslufthavnen, uanset hvilken vej sætningen løber. Flyselskabskoder, PNR og e-ticketnumre er latinske strenge sluppet ned i arabiske sætninger, og er de ikke isolerede, omarrangerer browserens bidirektionelle algoritme tegnsætningen omkring dem — en record locator efterfulgt af et punktum kan blive gengivet med punktummet i den forkerte ende, hvilket for kunden ligner en tastefejl i hendes egen bookingreference. Dit logo spejles ikke. En play-trekant spejles ikke. En tilbage-pil gør.

Så kommer de ting, ingen når at liste, før en kunde nævner en af dem: rækkefølgen af valutasymbol og tal, trinindikatoren gennem bookingtragten, sædekortet, hvilken vej et karrusel bevæger sig, hvilken side af en resultatrække flyselskabets logo sidder på, og fra hvilken kant en bred pristabel scroller. Hver eneste af dem er en beslutning. Ingen af dem er et flag, man sætter.

Tal, datoer og den kalender, kunden faktisk har i hånden

Arabisk skrives med to talsæt, der begge er i almindelig brug, og rejser er fulde af tal: priser, tider, rejsetider, bagagegrænser, kortfelter, OTP-koder. Hvilket sæt dit marked læser er et spørgsmål, man besvarer én gang, med sine egne kunder, og derefter anvender uden undtagelse. Den synlige fejl er ikke at vælge det mindre udbredte. Den er at blande dem — en pris i det ene og en afgangstid i det andet på samme resultatkort — hvilket læses som en halvfærdig side.

Datoer bærer flere antagelser end tal gør. En uge, der begynder om mandagen, er forkert for en kunde, hvis uge begynder om søndagen, og en kalender, der starter på den forkerte dag, forårsager præcis én slags fejl: en booking én kolonne ved siden af. En kunde, der planlægger umrah, regner i en hijri-måned, ikke en gregoriansk, og at vise hijri-datoen ved siden af den gregorianske i datovælgeren og på rejseplanen koster ingenting og sparer et opkald. At vise den overalt, på en forretningsrejse til Frankfurt, er støj.

Hvad en arabisk bookingside skal ramme

Afstanden mellem en oversat og en lokaliseret side er flade for flade, ikke global. Det her er listen, der er værd at diskutere med din udvikler:

Navnerækken er den, der koster rigtige penge, og den er oftest forkert. En rejsende skriver sit navn på arabisk, fordi formularen inviterede til det, billetten udstedes mod den streng, og den matcher ikke det pas, flyselskabet kontrollerer. Alt nedstrøms — ombookingen, diskussionen, refusionen — lander hos dig og ikke hos transportøren.

Skriftrækken er billigere, end den ser ud. På denne platform kan temaet, inklusive skrifter, farver og logo, skiftes fra adminpanelet uden redeploy, så at prøve en anden arabisk skrift mod din egen pristabel er en eftermiddag snarere end en release. Valutarækken er et emne for sig; vi gik den igennem i bookingside med flere valutaer og hvor marginen siver.

Slugs, og hvad der overlever en WhatsApp-indsættelse

En arabisk slug gengives smukt i adresselinjen og består af de ord, folk rent faktisk skriver i et søgefelt. Kopieret ind i et almindeligt tekstfelt bliver den procentkodet og svulmer flere gange op, og det din kunde videresender, ligner maskinoutput. En latinsk translitteration indsættes rent og er ulæselig for alle — den matcher intet, en arabisk læser søger på, og intet, en engelsk gør.

Del beslutningen efter, hvad URL'en er til. En indholdsside lever eller dør på søgning, så giv den sluggen i sit eget skriftsystem; den kodede form dukker kun op, når nogen kopierer den, og siden den lander på er rigtig i begge tilfælde. Et bookingdeeplink — et søgeresultat, en holdt pris, et tilbud til en underagent — bliver alligevel aldrig pænt, for det bærer datoer og passagerantal i query-strengen. Giv det et kort link, og lad det blive kort.

Reglen under begge: én kanonisk URL per side per sprog. At udgive samme artikel på en arabisk slug og en translittereret deler alt, hvad den side tjener, mellem to adresser og efterlader dig med at vedligeholde begge.

hreflang, ellers konkurrerer din arabiske side med din engelske

To sprogversioner af én side er ikke to sider. Kan en crawler ikke afgøre det, er det almindeligste udfald ikke en straf — det er, at én version vælges, og den anden behandles som near-duplicate og stille falder ud.

Fire ting holder dem adskilt. Hvert sprog har brug for sin egen URL, hvilket udelukker én adresse med en JavaScript-skifter. Hver version lister alle sprog inklusive sig selv, for et sæt, der ikke peger tilbage på sig selv, kasseres i sin helhed. Hver sides canonical peger på sig selv, ikke på den engelske original — arabiske sider kanoniseret mod engelsk er den hurtigste vej til slet ikke at have arabiske sider indekseret. Og x-default går derhen, hvor du vil have en læser uden match til at lande.

Modstå at splitte i ar-AE og ar-SA, medmindre de sider virkelig er forskellige — anden valuta, andet telefonnummer, andet udbud. To regionale varianter af identisk tekst er to sider, der slås om den samme søgning, begge med dit navn på.

Hvad det koster dig, når det er forkert

Frafaldet sker ikke på forsiden. Det sker ved passageroplysningerne, som er det dyreste sted i tragten at miste nogen: kunden har allerede søgt, valgt, set prisen og sagt ja til den, og du har allerede betalt for den søgning, der bragte hende derhen.

Resten af omkostningen er mere stille. Hver forvirret opringer er et medarbejderminut, du gik online for at spare. Hvert navnemismatch er en ombooking og en kunde, der bebrejder dig frem for flyselskabet. Og en arabisk side, der aldrig bliver indekseret, er en artikel, du har betalt for, som ingen kan finde — den eneste slags fejl, der slet ikke producerer klager, hvilket er grunden til, at den kan køre i et år.

Hvor du begynder

Er arabisk dit andet marked, er arbejdet en eftermontering, og tabellen ovenfor er din punchliste. Er det dit første, vender rækkefølgen: vælg talsæt og arabisk skrift før farveskemaet, byg passagerformularen mod et rigtigt pas, og behandl engelsk som oversættelsen.

Under alle omstændigheder er den billigste test en rigtig storefront foran en rigtig kunde. Guiden på opret en rejseside opretter en brandet side på et platformssubdomæne direkte fra formularen og beder ikke om et kort; storefronten kører på 40 sprog, arabisk, farsi, hebraisk og urdu iblandt, med dit eget domæne tilkobleligt senere. Overvejer du stadig at bygge motoren selv, er det regnestykke gennemgået her — men gør det på arabisk, før du beslutter dig, for RTL-arbejdet er præcis den del, interne estimater lader ligge.