Translations

Located in resources/lang/<locale>.json. Example:

{
    "password_reset_text": "Sie erhalten diese E-Mail weil wir eine Anfrage erhalten haben Ihr Passwort zurückzusetzen.",
    "password_reset_action": "Passwort zurücksetzen",
    "password_reset_request": "Passwortzurücksetzungsanfrage",
    "module": {
        "fields": {
            "phone": "Telefonnummer"
        }
    },
    "modules": {
        "permissions": {
            "title": "Berechtigungen",
            "fields": {
                "operation": "Operation",
                "guarded_module": "Geschütztes Modul",
                "field": "Geschütztes Feld",
                "resource": "Geschützte Resource"
            }
        },
        "roles": {
            "title": "Rollen",
            "fields": {
                "name": "Name",
                "permissions": "Berechtigungen"
            }
        },
        "users": {
            "fields": {
                "roles": "Rollen"
            }
        }
    }
}

Here we can see two kinds of generalization features.

First, the whole JSON structure is always merged recursively with the specialized system translation, meaning the system translation can overwrite all keys at will. Arrays and objects are merged in every level. We can define default values for keys in the normal frontend, like buttons, or we can define default values for fields of modules with specific identifiers, e.g. “permissions”, “roles” and “users”.

Second, the “module” key is used to indicate default translations for all modules. For example, use it to define default field names, e.g. if the translation for “phone” should be “Telefonnummer” by default in all modules. Each module can overwrite these translations. What is even more awesome: each system can define its own default module behavior by overwriting the value of the “module” key itself! For instance, in one system “number” might literally just be “Zahl”, while in another system “number” might always be “Nummer”.