En arabisk bestillingsside er ikke en oversettelse

Et reisebyrå i Jeddah slår på arabisk, ser på forsiden og bestemmer at jobben er gjort. To uker senere videresender en kunde en prislenke til søsteren sin på WhatsApp, og den kommer fram som en vegg av prosenttegn. En annen ringer fordi totalsummen dukket opp på den siden av prisen hun regner som feil. En tredje bestiller Riyadh–Dubai på feil dag, fordi kalenderen begynte uken på en mandag. Ingen av delene er en oversettelsesfeil. En arabisk bestillingsside er et oppsett, et tallsystem og et URL-skjema før den er en samling strenger — og strengene blir gjort først, fordi de er den delen du kan se på et skjermbilde.
For et norsk byrå er dette ikke eksotisk. I det øyeblikket du selger mot Gulfen, betjener arabisktalende kunder eller drifter en storefront for en partner i Emiratene, gjelder nøyaktig samme liste. Dette er det som faktisk endrer seg, omtrent i den rekkefølgen byråer møter det.
RTL er en oppsettsbeslutning, ikke en tekstretning
Å sette dir="rtl" speiler siden. Navigasjonen flytter til høyre, filterfeltet til venstre, avsnittene høyrestilles. Den delen er nesten gratis. Det dyre er alt som ikke skal speiles.
Avgangstider speiles ikke: 07:45 er 07:45. En rutestripe som leses DXB til CAI må fortsatt leses som en rute i den rekkefølgen inne i et høyrelest avsnitt, fordi avreiseflyplassen er avreiseflyplassen uansett hvilken vei setningen løper. Flyselskapskoder, PNR og e-ticketnumre er latinske strenger sluppet ned i arabiske setninger, og er de ikke isolert, stokker nettleserens toveis algoritme om tegnsettingen rundt dem — en record locator fulgt av punktum kan rendres med punktumet i feil ende, noe kunden leser som en skrivefeil i sin egen bestillingsreferanse. Logoen din speiles ikke. En play-trekant speiles ikke. En tilbakepil gjør det.
Så kommer tingene ingen rekker å liste opp før en kunde nevner en av dem: rekkefølgen på valutasymbol og tall, trinnindikatoren gjennom bestillingstrakten, setekartet, hvilken vei en karusell beveger seg, hvilken side av en treffrad flyselskapets logo sitter på, og fra hvilken kant en bred pristabell ruller. Hver av dem er en beslutning. Ingen av dem er et flagg du setter.
Tall, datoer og kalenderen kunden faktisk holder i
Arabisk skrives med to tallsett som begge er i vanlig bruk, og reiser er fulle av tall: priser, tider, reisetider, bagasjegrenser, kortfelt, OTP-koder. Hvilket sett markedet ditt leser er et spørsmål å svare på én gang, med dine egne kunder, og deretter bruke uten unntak. Den synlige feilen er ikke å velge det minst vanlige. Den er å blande dem — en pris i det ene og en avgangstid i det andre på samme treffkort — noe som leses som en halvferdig side.
Datoer bærer flere antakelser enn tall gjør. En uke som begynner på mandag er feil for en kunde hvis uke begynner på søndag, og en kalender som starter på feil dag forårsaker nøyaktig én slags feil: en bestilling én kolonne ved siden av. En kunde som planlegger umrah regner i en hijri-måned, ikke en gregoriansk, og å vise hijri-datoen ved siden av den gregorianske i datovelgeren og på reiseplanen koster ingenting og sparer en telefon. Å vise den overalt, på en forretningsreise til Frankfurt, er støy.
Hva en arabisk bestillingsside må treffe
Gapet mellom en oversatt og en lokalisert side er flate for flate, ikke globalt. Dette er listen det er verdt å diskutere med utvikleren din:
| Flate | Bare oversatt | Faktisk lokalisert |
|---|---|---|
| Passasjernavn | Feltetiketter på arabisk | Innfylling med latinske bokstaver, merket slik det står i passet, for det er navnet flyselskapet har i sin PNR |
| Datoer | Månedsnavn på arabisk | Leserens første ukedag, leserens tall, hijri ved siden av gregoriansk der reisen krever det |
| Penger | Valutanavnet oversatt | Markedets standardvaluta, og listen du faktisk selger i |
| Telefon og OTP | Etiketter på arabisk | Markedets landkode forhåndsvalgt, latinske tall i feltet, koden lesbar med ett blikk |
| Flyplasser og byer | Navn på arabisk | Arabisk navn med den latinske IATA-koden fortsatt synlig, for en underagent taster DXB og en reisende leser arabisk |
| URL-er | Tittelen oversatt | Én slugpolicy per språk, bestemt én gang |
| Skrift | Systemets arabiske reserveskrift | En arabisk skrift valgt for tallene sine og for små størrelser, ikke en latinsk skrift med arabisk lånt inn bak |
| Kontakt | En oversatt kontaktside | Et nummer en kunde i det markedet faktisk kan ringe, i timer hun er våken |
Navneraden er den som koster ekte penger, og den er oftest feil. En reisende skriver navnet sitt på arabisk fordi skjemaet inviterte til det, billetten utstedes mot den strengen, og den stemmer ikke med passet flyselskapet kontrollerer. Alt nedstrøms — ombestillingen, diskusjonen, refusjonen — lander hos deg og ikke hos transportøren.
Skriftraden er billigere enn den ser ut. På denne plattformen er temaet, inkludert skrifter, farger og logo, byttbart fra adminpanelet uten ny utrulling, så å prøve en annen arabisk skrift mot din egen pristabell er en ettermiddag snarere enn en release. Valutaraden er et eget tema; vi gikk gjennom den i bestillingsside med flere valutaer og hvor marginen lekker.
Slugger, og hva som overlever en WhatsApp-innliming
En arabisk slug rendres vakkert i adresselinjen og består av ordene folk faktisk skriver i et søkefelt. Kopiert inn i et vanlig tekstfelt blir den prosentkodet og sveller flere ganger, og det kunden din videresender ser ut som maskinutskrift. En latinsk translitterasjon limes rent og er uleselig for alle — den matcher ingenting en arabisk leser søker på og ingenting en engelsk gjør.
Del beslutningen etter hva URL-en er til for. En innholdsside lever eller dør på søk, så gi den sluggen i sitt eget skriftsystem; den kodede formen dukker bare opp når noen kopierer den, og siden den lander på er riktig uansett. En bestillingsdeeplenke — et søkeresultat, en holdt pris, et tilbud til en underagent — kommer uansett aldri til å bli pen, for den bærer datoer og passasjerantall i query-strengen. Gi den en kort lenke og la den forbli kort.
Regelen under begge: én kanonisk URL per side per språk. Å publisere samme artikkel på en arabisk slug og en translitterert deler alt den siden tjener mellom to adresser og lar deg vedlikeholde begge.
hreflang, ellers konkurrerer den arabiske siden med den engelske
To språkversjoner av én side er ikke to sider. Om en crawler ikke kan avgjøre det, er det vanligste utfallet ikke en straff — det er at én versjon velges og den andre behandles som near-duplicate og stille faller bort.
Fire ting holder dem fra hverandre. Hvert språk trenger sin egen URL, noe som utelukker én adresse med en JavaScript-bryter. Hver versjon lister alle språk inkludert seg selv, for et sett som ikke peker tilbake på seg selv forkastes i sin helhet. Hver sides canonical peker på seg selv, ikke på den engelske originalen — arabiske sider kanonisert mot engelsk er den raskeste veien til ikke å ha arabiske sider indeksert i det hele tatt. Og x-default går dit du vil at en leser uten treff skal lande.
Motstå å splitte i ar-AE og ar-SA med mindre de sidene virkelig er forskjellige — annen valuta, annet telefonnummer, annet utvalg. To regionale varianter av identisk tekst er to sider som slåss om samme søk, begge med navnet ditt på.
Hva det koster deg når dette er feil
Frafallet skjer ikke på forsiden. Det skjer på passasjeropplysningene, som er det dyreste stedet i trakten å miste noen: kunden har allerede søkt, valgt, sett prisen og sagt ja til den, og du har allerede betalt for søket som brakte henne dit.
Resten av kostnaden er stillere. Hver forvirrede oppringer er et medarbeiderminutt du gikk på nett for å spare. Hvert navnavvik er en ombestilling og en kunde som klandrer deg heller enn flyselskapet. Og en arabisk side som aldri blir indeksert er en artikkel du har betalt for som ingen kan finne — den eneste typen svikt som ikke produserer klager i det hele tatt, og derfor kan den gå i et år.
Hvor du begynner
Er arabisk ditt andre marked, er arbeidet en ettermontering, og tabellen over er punchlisten din. Er det ditt første, snur rekkefølgen: velg tallsett og arabisk skrift før fargeskjemaet, bygg passasjerskjemaet mot et ekte pass, og behandle engelsk som oversettelsen.
Uansett er den billigste testen en ekte storefront foran én ekte kunde. Veiviseren på lag en reiseside setter opp en merkevaresatt side på et plattformsubdomene rett fra skjemaet og ber ikke om kort; storefronten går på 40 språk, arabisk, farsi, hebraisk og urdu blant dem, med eget domene som kan kobles på senere. Vurderer du fortsatt å bygge motoren selv, er det regnestykket gjennomgått her — men gjør det på arabisk før du bestemmer deg, for RTL-arbeidet er nettopp den delen interne estimater utelater.