Skyscanner is used by a whopping 100 million global users every month. Our website and app are available in 37 different languages across 70 markets, with over 70% of our users coming from markets where English isn’t their first language.

Because of this, our Localisation experts sit in the Product Design team as we know how important it is to include them throughout the end-to-end product development flow. We want each user to feel as though the product was developed for them.

---

Content considerations

These guidelines have our best-practice guidance on creating high-quality localised experiences. Go to the General Engineering Production Standards for Localisation on GitHub for even more information.

Best practices for placeholders

Use placeholders for dynamic values

Always use placeholders for dynamic values of data instead of hard coding or omitting any information/placeholder. The placeholders need flexibility to be moved around in the string for other languages’ sentence structures.

Localise placeholder values

Variable information and dynamic data in interfaces must be localised for the relevant markets.

Use descriptive placeholders

Descriptive placeholders help translators understand what information will be displayed such as time, city, airport, price etc. Use clear and consistent placeholders to help create accurate translations.

Flights from {origin_airport}

Flights from {0}

Use clear and specific placeholders

Vague placeholders such as {destination} could be interpreted as an airport, origin city or even country. Some languages use different grammatical structures for each different case. The placeholders must be clear about what the data set is.

Flights to {city}

Flights to {country}

Flights to {airport}

Flights to {destination}

Use the correct placeholder format

Use the placeholder format supported by the Strings Dashboard and the project the string is created in.

When strings are sent for translation placeholders are blocked to become uneditable to prevent errors. The placeholder won’t be recognised if an unsupported format is used or if one of the opening/closing symbols is missing. In this case, the source copy will need to be updated and sent for translation again.

Leave punctuation and symbols outside of placeholders

Some languages use punctuation and symbols differently from English or use different symbols altogether. Leave them outside of placeholders to avoid mistranslation.

Save {0}%

Save {0%}

---

Sourcing data for strings

Use Culture Service for times, dates and currencies

Skyscanner uses the Culture Service on the back end for cultural meta-data such as time, date formats and local currencies. The values are already localised, so use this database to maintain consistency across the products. The provided ‘Test Harness’ needs the dev proxy to be run locally.

On the front end, Skyscanner uses saddlebag-localisation for any date/timezone localisation.

Visit the Web Production Standard for dates and time zones on GitHub for more information.

Use Tellus for geodata

Tellus is where information about geodata is stored, including translations of the main geographical entities. The data includes:

• Geopolitical entities (cities, districts, nations etc.)
• Geographical entities (islands, seas etc.)
• Business entities and their relationships with airports, hotels, car hire offices and points of interest

Skyscanner services use AtlantisAPI to geolocate their business entities, and TravelAPI and FlightsGeo to explore it.

Translating strings

Add context for the string

It’s important to add context for strings when using the Strings Dashboard as external linguists translate in isolation one string at a time. For example, “Return flight” in English can mean both an inbound flight and a round-trip, but most languages have different terms for each meaning.

Add contextual information for:

• How and where the string will be used.
• Use cases and behaviour for interactions.
• Up-to-date screenshot of the English design for reference.
• SEO strings – add page type and element (H1, meta title etc.) with any keywords.

Create separate strings for singulars and plurals

Pluralisation is handled differently from language to language. Create separate strings for singular and plural formats so the translator can translate accordingly.

Don’t concatenate strings

Concatenation is when separate strings are joined together to form a sentence. The word order and sentence structure may vary in different languages meaning the strings read in an unnatural or illegible manner.

Here you can see the structural difference between English and Chinese for the string “From {price} per day”. If the three separate strings later merge in the design, the order of the strings won’t be correct in all languages.

Translate strings as full sentences. For example “From {price} per day”

Don’t translate strings individually. For example:

String 1: From

String 2: {price}

String 3: per day

Aim to submit project strings in the same batch

When submitting strings for a feature, page or user flow, submit them at the same time so the translator has a view of the wider context to keep content consistent.

Avoid reusing strings for different contexts

English strings from other projects may be able to be reused in different contexts, however, when translated they may not make any sense. The context must be the same if you wish to reuse a string.

Send content for translation when it’s finalised

Check copy in the designs is the final version and approved by Content Design before submitting the strings for translation, and provide the Localisation team with the final design as a reference.

---

Writing code for translation

Don’t hard code strings

Product strings must allow for different sentence structures, word orders, time/date formats, and length. Instead of hardcoding data, use placeholders that can be moved around in the sentence

Enable right-to-left alignment

The product needs to accommodate right-to-left languages such as Arabic and Hebrew. Create code that allows text direction to be changed.

Visit the Web Production Standard for RTL on GitHub for more information.

Don’t capitalise strings using code

Forcing capitalisation may lead to grammatical errors as some languages don’t use title case. Casing should be done by the translators so the language-specific case mapping rules can be applied correctly. Title case is also not aligned with the Skyscanner house style.

How to consume translations

It’s recommended to use the Translations Bot to get strings into your services. Once configured, it will check for any translation changes every time a change is merged and create a new 'pull request' with those changes. This allows for repeatable builds and removes the runtime dependency on the Strings Service.

Alternatively, the Strings Service provides dynamic translations through direct API calls or the available client libraries.

---

Got a question?

Drop the team a message in #localisation and they'll be happy to help.