This section states the best practices for using the Language within your application.

Code standards

JSON structure Sometimes we'll need global words within our app but there will be cases that are limited to any of your app scopes. In that sense, when defining the language JSON you should nest the keys depending on the group (app scope) they belong to.

✅ DO

en: {
	// Words that are global to our app are not defined under a parent key
  open: "Open",
  saveChanges: "Save changes",
  ...
	// Words that are scoped to any of our app sections
	// are defined under a parent key (Ex. *filters*)
  filters: {
    onlyFiltersTerm: "First filters term",
    otherFiltersTerm: "Second filters term",
    ...
  }
}

❌ DON'T

es: {
  open: "Abrir",
  saveChanges: "Guardar cambios",
  filtersTerm: "Término de filtros",
  otherFiltersTerm: "Otro término de filtros"
}

Defining lang keys

The key names must be in English, written in camel case, consistent, and hold specific information of what the key stands for.

✅ DO ❌ DON'T Reason
noResults sinResultados Keys must be in English
goBack goback Use camel case to differentiate words
sendEmail send**-e**mail, send_email, send$email Use camel case instead of —
transactionalShipments trShip, tShip They have to hold meaning
noResults searchReturnedNoResults Name length must have just the right size

⚠️ Avoid having different keys meaning the same word.

Getting lang keys from Ditto

We’re actually working on an automatic flow to get the Ditto internationalization information, but for now we can actually pass the flat JSON to our developers and they can format that info following the Get Ditto keys

Ditto meeting Front notes

In Spanish ‘cuz I’m asking this in the Ditto meeting :v

En caso de que lo de arriba falle o no funcione podemos: