# Introduction

https://www.sanity.io/learn/course/localization/introduction.md

Learn what this course will cover

In this course we'll walk through how you can localize your content in Sanity in a way that ensures an organized experience for content authors. We'll cover:

* Creating a source of truth for your locales with a `locale` content type
* Selecting the right localization method based on your content model
* Implementing both localization methods in Sanity's blog starter
* Implementing AI Assist for automated translation of content

## Terminology

There are some terms worth understanding when talking about localization

* **Internationalization (i18n)** - The process of designing and developing your front-end to allow it to be viewed in multiple languages.
* **Localization** - The actual adaptation of your content and front-end UI to be shown in a specific language.
* **Language tag** - As defined in the [IETF RFC 5646](https://datatracker.ietf.org/doc/html/rfc5646) (a specification for codes to localize content), a language tag is a full string representing the language (and optionally region and script) for a given piece of content. “zh”, “zh-CN”, and “zh-CN-Hant” are all examples of language tags.
* **Subtag** - Language subtags are the sections of a language tag delineated by a hyphen. Using the previous example “zh”, “CN”, and “Hant” are all subtags of the language tag “zh-CN-Hant”. As you can also see in the above example, sometimes a single subtag defines a full language tag. There are 3 different types of subtag - language, region, and script, and language tags are constructed with the subtags in that order.
* **Locale** - Locale is a helpful descriptor for a language tag containing both language and region information.

## Guiding principles

### The priority should be an easy authoring experience

The structured nature of Sanity’s schemas and the flexibility of the GROQ query language make it easy to parse and filter localized content for consumption within a front-end; as such there are few if any cases where your localization approach should be decided to satisfy the needs of your front-end architecture.

### Avoid duplicates of content

It’s a common pitfall to end up with several nearly identical copies of the same pieces of content with very slight differences between them. For example, content in US English and British English, where most of the content is the same except for slight spelling differences, or legal copy that is shared across the US and Canada, but with a few paragraphs excluded in the Canadian version. Portable Text makes it easy to re-use as much content as possible, while using marks and custom blocks to swap out words or entire sections as-needed.



With that in mind, let's look at creating a `locale` content type