---
layout: default
title: "Language"
---
A language (or locale) on WebTranslateIt is defined by a set of parameters like the user’s language, country and any special variant preferences that the user wants to see in their user interface. Usually a language consists of at least a linguistic identifier and a regional identifier (for instance: English + United States will be "en-US").
When creating a project in WebTranslateIt, you are required to choose a source language, as well as several target languages.
## Languages and Files
Files are mapped to languages in the [File Manager](/en/docs/file_manager). For instance, when you add a language, WebTranslateIt automatically creates target files for each master file in the File Manager.
Furthermore, when you add a new master file in WebTranslateIt, target files are automatically created and mapped to existing languages.
Deleting a language deletes the related files in the File Manager.
## Creating Languages
The language builder allows you to construct languages. To use it, start by typing the beginning of the language you want to use.
In the example above, I typed “az” and the language builder offers me a large choice of languages:

Language Name

Language Code

Script

Azerbaijani

az

Latin

Azerbaijani (Arabic)

az-Arab

Arabic

Azerbaijani (Cyrillic)

az-Cyrl

Cyrillic

Azerbaijani (Latin)

az-Latn

Latin

Azerbaijani, Azerbaijan

az-AZ

Latin

Azerbaijani, Azerbaijan (Arabic)

az-AZ-Arab

Arabic

Azerbaijani, Azerbaijan (Cyrillic)

az-AZ-Cyrl

Cyrillic

Azerbaijani, Azerbaijan (Latin)

az-AZ-Latn

Latin

WebTranslateIt knows relevant informations about each languages:
* Which countries (or territories) use a language,
* Which scripts a language is written in (for instance: `Latin`, `Arabic`, `Cyrilic`, ...),
* Which script is the official one or mostly used one.
If your language doesn’t provide an explicit script (like the language code `az` for instance) an implicit language is chosen for you: `Latin` in Azerbaijani’s case. If you’d rather use another script you can build a language with the correct script. The default language is the official or most important script for a language or for a language/country compound.
## Hyphen and Underscore
It is better to use a hyphen (or dash) rather than an underscore sign to separate the language code, the country code and the script code. [RFC 3066](http://www.ietf.org/rfc/rfc3066.txt) recommends using `en-GB` instead of `en_GB`:
> Language tag syntax
>
> The language tag is composed of one or more parts: A primary language
> subtag and a (possibly empty) series of subsequent subtags.
>
> The syntax of this tag in ABNF RFC 2234 is:
>
> Language-Tag = Primary-subtag \*( "-" Subtag )
>
> Primary-subtag = 1\*8ALPHA
>
> Subtag = 1\*8(ALPHA / DIGIT)
>
> The productions ALPHA and DIGIT are imported from RFC 2234; they
> denote respectively the characters A to Z in upper or lower case and
> the digits from 0 to 9. The character "-" is HYPHEN-MINUS (ABNF:
> %x2D).
>
> All tags are to be treated as case insensitive; there are
> conventions defining the use of capitalization.
> For instance, ISO 3166 recommends that
> country codes are capitalized (MN Mongolia), while ISO 639
> recommends that language codes are written in lower case (mn
> Mongolian).
>
However, even if using a hyphen (or dash) is better, some software use underscores (`en_GB`), so you can choose to use dashed language tags in your project settings.
This setting impacts the generated file names, the API URLs, and in some linguistic files the language code used.
## Customizing Languages
Sometimes you’ll want to create your own language. For instance, if your development team writes an English copy that needs to be proofread, you might want to create a fake language “English by developers”. The copy in this language will, in turn, be modified and proofread by a professional proofreader before being translated into other languages.
Another reason could be that your app needs a specific custom language based on a very specific location.
In the Language Manager, start by choosing a base language. Then, click on “Create a specific language” to toggle additional options.
These additional options will be appended to the base language code and name.
* Suffix code is a code that will be appended to the language code. For instance: `dev`.
* Suffix description is the description of the suffix you add. For Instance `by developers`.
This will generate a new custom language with the code `en_dev` and name “English by developers”.
## Language Inheritance
> This feature is unavailable to organizations on a “Legacy” plan. It is only available for organizations on a Free Trial, or on the Micro, Small, Medium, Large, Extra Large plans and onwards.
> You can upgrade your organization from a “Legacy” plan to the new plans on the organization Billing page.
Language inheritance lets you define a hierarchy in the languages of a project. It lets you re-use and extend translations for languages having similarities, but yet are different.
It is easier explained with an example. The French language is spoken in many countries: France, Belgium, Canada, ... Using this feature you could define a general language `French` with the `fr` language code on which you would save generic French translations.
French spoken in Canada is very different than French spoken in France. Then you could then create a `French (Canada)` language with the `fr-CA` language code to write translations specific to the French language as spoken in Canada.
Using inheritance, translations in `fr` will automatically fill the translations in `fr-CA` unless a specific translation in `fr-CA` is saved. It means you no longer have to manually fill all the `fr-CA` translations. You only need to correct the translations where a specific translation for `fr-CA` should be used.
### Getting Started
Under the “Language & Stats” tab, click to add a new language. Start by typing the name of your new language. In our example, `fr-CA`.
Then, choose the name of its parent language. In this case the parent language is `fr`.
Then click on "Add this language". As usual, its language files will be automatically created in the [File Manager](/en/docs/file_manager) for you. The language will be listed in the list of languages and marked as an **inherited language**.
In the translation interface, translations for inherited languages are listed differently. If no specific translation is entered for the inherited language then only the translation for the more generic language is visible (if available). If a specific translation was entered, then both the specific translation for the inherited language and the generic translation will be visible.
### Advanced Option
An option is available in the project settings. It lets you choose:
- if you want the inherited language files to include translations from the parent source language
- or if you want the inherited language files to only include the differences and have the rest of the segments filled with `nil` values.
As an example, let’s consider this `fr.yml` file assigned to the `fr` language:
``` yaml
fr:
key1: "texte 1"
key2: "texte 2"
key3: "texte 3"
```
We’ve created a language `fr-CA` which inherits from `fr`. In that language, only the segment with key `key1` was updated with a specific translation.
If you choose to have the inherited language file filled with only the text having a difference you’ll obtain this language file:
``` yaml
fr-CA:
key1: "A different text"
key2: ~
key3: ~
```
(The `~` signs represents a `nil` value in the [YAML language file format](/en/docs/file_formats/yaml)).
If you choose to have the inherited language file to include translations from the source language you’ll obtain this language file:
``` yaml
fr:
key1: "A different text"
key2: "texte 2"
key3: "texte 3"
```