Skip to content

Latest commit

 

History

History
61 lines (37 loc) · 4.01 KB

LOCALIZATION.md

File metadata and controls

61 lines (37 loc) · 4.01 KB

Localization in Skratsj

Skratsj comes with support for English and Norwegian, though you can add more languages or remove language support if you don't need it.

The implementation is based on the suggested way of adding localization in the Sanity documentation.

Manage languages

To change the language support, you need to do a few changes. The quick changes are to your code; your schemas and in your client. When adding a new language you'll also want to update the content in your content studio, which depending on the amount of text to write may take longer.

1. Updating schemas

In the Sanity schemas directory there are two schemas called localeString.js and localeText.js.

You will see that localeString and localeText have two fields with title English and Norwegian. You can add, remove or change fields to manage which languages are supported in your Content Studio.

Note that changing the schema only affects how the Content Studio relates to the data in the dataset, i.e. how it presents it and what it allows you to input. Changing the schema does not change the content that exists in your dataset.

2. Updating data through Content Studio

After updating schemas, you can edit the content in your dataset through your content studio (localhost:3333). (Alternatively, you can migrate data using scripts if you have altered the data structure or renamed/removed fields.)

3. Updating client

The client relates to localization in three ways, as explained in the following sections.

I) Selecting language

Firstly, there is a LanguageSelector component that lets the user select between the available languages. Out of the box, Skratsj links to skratsj.com to get English and skrætsj.no to get Norwegian. In util/localize.js the preferredLanguage is decided based on the current URL.

Update LanguageSelector and util/localize.js to suit your needs.

II) Querying data

We use the currently selected language when we query localized data from Sanity. This is done in personStore.js), see snipped below.

const localized = {
  english: fieldName => `"${fieldName}": ${fieldName}.en`,
  norwegian: fieldName => `"${fieldName}": coalesce(${fieldName}.nb, ${fieldName}.en)`,
}[preferredLanguage];

function apiCall() {
  return client.fetch(
    `*[_type == 'person'] | [0] {
      name,
      image,
      ${localized('title')},
      ${localized('introduction')},

We create a function localized, which is different depending on the value of preferredLanguage which can be either "english" or "norwegian". We then use the localized function to build the query, see examples on the last two lines of the snippet.

  • If selectedLanguage is "english", ${localized('title')} inlines "title": title.en into the query.
  • If selectedLanguage is "norwegian", ${localized('title')} inlines "title": coalesce(title.nb, title.en) into the query.

III) Hard-coded text

The titles for the various sections of the CV are hard-coded inline. If you search in the client/src/ directory for }[preferredLanguage]} you will find 14 matches across 10 files, where you'll need to add support for any new languages you add.

Additionally, the message rendered while loading content (and if the network call fails), is localized in RequestStateFeedback.js. (Here theyre wrapped in components to allow HTML like linebreaks and links in the text.)