Internationlisation

All translations can currently be found here, embedded below for reference. We use vue-i18n, you should read it's documentation:

Vue I18n | Vue I18n

Translations

Principles

Locatability

The key should make it clear what part of the application is using the string. We haven't formally defined what this means but keys used in the same part of the application should be in the same namespace.

Greppability

Keys should be greppable, meaning they should be written out in full in code so you could easily search for them. This makes it simple to check the codebase to see if strings are still in use.

const s = t('the.full.key.is.here'); // GOOD

const key = 'is.here';
const s = t('the.full.key.' + key); // BAD

We make a the follow exceptions to this rule:

• Common enumerated values such as RoleType, ContributionPeriod, etc. This simplifies the code and we know that those will be used in any case. This probably only applies to keys in the common namespace.

const role = RoleType.Member;
const s = t('common.roleType.' + role);

• Extremely long keys where code readability becomes a problem. In this case you should define a function which concatenates the key with the base key

function stepT(key: string) {
  return t('this.is.a.really.long.base.key.' + key);
}

Reserved namespaces

actions

All actions should go in the actions namespace unless they are very specific to a specific part of the application. We should be aiming to have a simple and shared language for actions across the site, by keeping all the actions together we get a good idea of what that looks like.

common

Common words/phrases that are used across the application. Phrases should be grouped under a subnamespace, although historically this hasn't happened.

form

This namespace is a bit of a mess at the moment, but we should aim to having common form language in here, possibly some of this should be moved into common

form.errors

This is for field validations. The form validation within AppInput, AppSelect, etc. automatically generates keys based on the field name and validation type. For example

<AppInput name="yourEmail" type="email" required />

This can have the following validation messages:

• form.errors.yourEmail.email: Invalid email address format

• form.errors.yourEmail.required: Field is required

An input without a name attribute defaults to the form.errors.unknown namespace

<model>.data.<field>

The localised name for a field should be within a .data. subnamespace.

Modifiers

Keys can be given modifiers to change how they are parsed by the processing script, these are delimited using a colon (:) at the end of the string. Colons are therefore a special character within keys and can't be used within the key name.

Markdown

Ending a key with :md means the contents will be parsed as a markdown string. This can be really helpful when wanting to add a bit of light touch formatting (e.g. bold, italic) without needing to separate the key into parts.