LookML-Modell lokalisieren

Durch Modelllokalisierung können Sie je nach Gebietsschema eines Benutzers individuell festlegen, wie die Bezeichnungen und Beschreibungen Ihres Modells angezeigt werden.

Die Lokalisierung muss nicht zwangsläufig auf geografischem Standort oder Sprache beruhen. Anhand von Gebietsschemata lassen sich andere charakteristische Faktoren darstellen, beispielsweise interne gegenüber externen Benutzern oder Manager gegenüber einzelnen Autoren. Ihre Bezeichnungen und Beschreibungen können dementsprechend angepasst werden.

Auf dieser Seite werden die Schritte zur Lokalisierung Ihres Projekts beschrieben:

  1. Legen Sie fest, welche Elemente lokalisiert werden sollen, indem Sie Ihrem Modell Bezeichnungen, Gruppenbezeichnungen und Beschreibungen hinzufügen.
  2. Geben Sie die Lokalisierungsdefinitionen für Ihr Projekt an, indem Sie Gebietsschema-Zeichenfolgendateien erstellen.
  3. Aktivieren Sie die Lokalisierung für Ihr Projekt, indem Sie der Manifestdatei des Projekts Lokalisierungseinstellungen hinzufügen.
  4. Legen Sie die Anzeige für verschiedene Benutzer fest, indem Sie Benutzer Gebietsschemata zuweisen.

Die Modelllokalisierung erfolgt häufig in Verbindung mit einem Administrator, der die Lokalisierung der Zahlenformate und die Spracheinstellungen für die Benutzeroberfläche festlegt.

Bezeichnungen und Beschreibungen in Ihrem Modell lokalisieren

Sie können Bezeichnungen, Gruppenbezeichnungen und Beschreibungen in Ihrem Modell lokalisieren. Hierzu zählen unter anderem:

Sie können auch lokalisierte LookML-Dashboards in Ihrem Projekt erstellen. Die folgenden Parameter des LookML-Dashboard können lokalisiert werden:

Wenn Sie alle Felder in Ihrem Projekt sehen möchten, die lokalisiert werden können, können Sie die Lokalisierungsebene Ihres Projekts auf strict setzen. Mit dieser Einstellung übergibt die Looker-IDE einen LookML-Validierungsfehler für alle LookML-Elemente, die zwar lokalisiert werden können, aber nicht über Bezeichnungen verfügen, sowie für alle Zeichenfolgen im LookML-Modell, die zwar lokalisiert werden können, aber nicht in Ihren Gebietsschema-Zeichenfolgendateien definiert sind.

Im folgenden LookML-Beispiel werden Bezeichnungen für die Ansicht flights und die Felder id, country und number_of_engines angegeben. Außerdem wird eine Beschreibung für das Feld country angegeben.

view: flights {
  label: "flight_info"
  sql_table_name: flightstats.accidents ;;

  dimension: id {
    label: "id"
    primary_key: yes
    type: number
    sql: ${TABLE}.id ;;
  }

  dimension: country {
    label: "country"
    description: "country_of_departure"
    type: string
    map_layer_name: countries
    sql: ${TABLE}.country ;;
  }

  dimension: number_of_engines {
    label: "number_of_engines"
    type: string
    sql: ${TABLE}.number_of_engines ;;
  }

  dimension: location {
    type: string
    sql: ${TABLE}.location ;;
  }
}

In den folgenden Beispielen auf dieser Seite lokalisieren wir diese Werte in den Zeichenfolgendateien mit der Lokalisierungsebene permissive. Die Dimension location hat keine Bezeichnung, sodass wir zeigen können, wie eine Dimension ohne Lokalisierung angezeigt wird.

Gebietsschema-Zeichenfolgendateien erstellen

Die Gebietsschema-Zeichenfolgendaten definieren mithilfe von Schlüsselwertpaaren, wie die Bezeichnungen und Beschreibungen in Ihrem Modell für jedes Gebietsschema angezeigt werden. Links des jeweiligen Schlüsselwertpaars befindet sich der Lokalisierungsschlüssel. Hierbei handelt es sich um eine Bezeichnungs- oder Beschreibungszeichenfolge aus Ihrem Modell. Rechts neben dem Schlüsselwertpaar definieren Sie, wie diese Zeichenfolge auf der Looker-Benutzeroberfläche angezeigt wird.

Für jedes Gebietsschema, das Sie für Ihr Projekt verwenden möchten, müssen Sie eine eigene Zeichenfolgendatei erstellen. Erstellen Sie nur eine Zeichenfolgendatei für jedes Gebietsschema. Sie benötigen eine Zeichenfolgendatei, deren Name mit dem Standardgebietsschema übereinstimmt. Wenn Sie beispielsweise default_locale: en in der Manifestdatei Ihres Projekts angegeben haben, muss in Ihrem Modell eine Datei mit dem Namen en.strings.json vorhanden sein. Jede Zeichenfolge muss in der Standard -Gebietsschema-Zeichenfolgendatei definiert sein. Andernfalls wird sie nicht lokalisiert.

Dieses Beispiel für eine en.strings.json-Datei wird für alle Benutzer mit dem Gebietsschema-Wert en verwendet. Im folgenden LookML-Beispiel ist en außerdem als Standardgebietsschema festgelegt. Das heißt, alle Zeichenfolgen müssen in dieser Datei definiert sein, damit sie lokalisiert werden.

{
  "flight_info": "Flights",
  "id": "Identifier",
  "country_of_departure": "Country of Departure",
  "number_engines": "Number of Engines"
}

In der folgenden Tabelle sehen Sie, was ein Nutzer mit dem Gebietsschema en in der Datentabelle eines Looker-Explores sehen würde:

Flights Identifier Flights country Flights Location Flights Number of Engines
493 Congo Kisangani, Congo 3
2167 Saudi Arabia Riyadh, Saudi Arabia 3
2657 Austria Vienna, Austria 2
17992 United States Kansas City, MO 2
18893 United States Anchorage, AK 4

Wichtige Hinweise:

Ein weiteres Beispiel: Wir können eine es_ES.strings.json-Datei erstellen, die für alle Benutzer mit dem Gebietsschema-Wert es_ES verwendet wird:

{
  "flight_info": "Vuelos",
  "id": "Identificador",
  "country": "País",
  "country_of_departure": "País de Partida",
  "number_engines": "Número de Motores"
}

In der folgenden Tabelle sehen Sie, was ein Nutzer mit dem Gebietsschema es_ES in Looker sehen würde:

Vuelos Identificador Vuelos country Vuelos Location Vuelos Número de Motores
493 Congo Kisangani, Congo 3
2167 Saudi Arabia Riyadh, Saudi Arabia 3
2657 Austria Vienna, Austria 2
17992 United States Kansas City, MO 2
18893 United States Anchorage, AK 4

Wichtige Hinweise:

  • Wie im vorherigen Beispiel wurde in der ursprünglichen Ansicht mit hinzugefügten Bezeichnungen und Beschreibungen keine Bezeichnung für die Dimension „location“ angegeben. Daher schreibt Looker den Namen der Dimension groß und zeigt ihn als „Location“ an.
  • In der Datei „en.strings.json“, der Standard-Gebietsschema-Zeichenfolgendatei, wurde keine Lokalisierung für die Bezeichnung „country“ definiert. Das heißt, obwohl „country“ in der Datei „es_ES.strings.json“ definiert wurde, lokalisiert Looker diese Zeichenfolge nicht und zeigt die Bezeichnung wie in der Ansichtsdatei definiert an: „country“.

Lokalisierungseinstellungen zur Manifestdatei Ihres Projekts hinzufügen

Wenn Sie die Lokalisierung für Ihr Projekt aktivieren möchten, fügen Sie der Manifestdatei des Projekts den localization_settings Parameter hinzu.

Fügen Sie in der Manifestdatei Ihre Lokalisierungseinstellungen hinzu. Beispiel:

localization_settings: {
  default_locale: en
  localization_level: permissive
}

default_locale

Der Parameter default_locale gibt den Namen der Standard-Gebietsschema-Zeichenfolgendatei in Ihrem Projekt an.

Die Standard-Gebietsschema-Zeichenfolgendatei bestimmt, welche Zeichenfolgen aus Ihrem Modell lokalisiert werden. Selbst wenn eine Bezeichnungs- oder Beschreibungszeichenfolge in einer anderen Gebietsschema-Zeichenfolgendatei definiert ist, wird auf der Looker-Benutzeroberfläche die nicht lokalisierte Zeichenfolge angezeigt, sofern sie nicht in der Standard -Gebietsschema-Zeichenfolgendatei definiert ist.

Verwechseln Sie das Standardgebietsschema für Ihr Projekt nicht mit dem Standardgebietsschema für Looker-Nutzer. Ihr Looker-Administrator kann ein Standardgebietsschema für Ihre Instanz festlegen. Wenn kein Standard festgelegt ist, verwendet Looker standardmäßig en. Wenn Ihr Administrator für einen Nutzer oder eine Nutzergruppe, zu der der Nutzer gehört, keinen Wert für Gebietsschema eingibt, weist Looker den Nutzer dem Standardgebietsschema der Instanz zu. Wenn der Administrator kein Standardgebietsschema für die Instanz festgelegt hat, weist Looker den Nutzer dem Gebietsschema en zu.

Sofern Sie sich also nicht ganz sicher sind, ob Ihr Looker-Administrator den Wert für Gebietsschema für all Ihre Looker-Nutzer festlegt, sollten Sie den Parameter default_locale des Projekts auf das Standardgebietsschema für Ihre Instanz setzen (oder auf en, wenn kein Standard festgelegt wurde) und die Lokalisierung für alle Bezeichnungen und Beschreibungen in der Datei .strings.json für dieses Gebietsschema definieren.

localization_level

Mit der Lokalisierungsebene Ihres Projekts wird angegeben, ob nicht lokalisierte Elemente in Ihrem Modell zulässig sind:

  • Setzen Sie die Lokalisierungsebene auf strict, um lokalisierte Bezeichnungen für alle Modelle, Explores, Ansichten und Felder in Ihrem Projekt zu erzwingen. Die Looker-IDE übergibt einen LookML-Validierungsfehler für alle diese Elemente, die keine Bezeichnungen haben, sowie für alle Bezeichnungen und Beschreibungen, die in der Standard-Gebietsschema-Zeichenfolgendatei nicht definiert sind.
  • Setzen Sie die Lokalisierungsebene auf permissive, um Elemente ohne Bezeichnungen sowie Bezeichnungen und Beschreibungen zuzulassen, die nicht in der Standard-Gebietsschema-Zeichenfolgendatei definiert sind.

Auch wenn Sie die Lokalisierungsebene strict verwenden möchten, kann es hilfreich sein, die Lokalisierungsebene Ihres Projekts während der Entwicklung auf permissive zu setzen, um Validierungsfehler zu vermeiden. Sobald Sie alle Bezeichnungen und Beschreibungen lokalisiert haben, können Sie die Lokalisierungsebene auf strict setzen, um Fehler zu sehen.

Benutzer einem Gebietsschema zuweisen

Sobald Ihre Gebietsschema-Zeichenfolgendateien eingerichtet sind, können Sie Benutzer einem Gebietsschema zuweisen, das einer Ihrer Gebietsschema-Zeichenfolgendateien entspricht. Dies kann auf Instanz-, Nutzergruppen- oder Einzelnutzerebene über das Feld Gebietsschema oder das Nutzerattribut locale erfolgen.

Wenn ein Nutzer beispielsweise die in der Datei es_ES.strings.json definierten Bezeichnungen und Beschreibungen sehen soll, muss Ihr Looker-Administrator die Einstellung Gebietsschema des Nutzers auf es_ES setzen.

Benutzerdefinierte Gebietsschemata, die Sie mit Zeichenfolgendateien erstellen, können Sie in das Feld Gebietsschema eingeben. Klicken Sie dazu auf das Feld und geben Sie den Namen der Zeichenfolgendatei ein, anstatt ein integriertes Gebietsschema aus dem Drop-down-Menü auszuwählen. Weitere Informationen finden Sie auf der Dokumentationsseite Nutzer.

Gebietsschema für Benutzer von signierten Einbettungen festlegen

Wie jedes andere Nutzerattribut können Sie den Gebietsschemawert eines Nutzers in eine signierte Einbettungs-URL einfügen. Das genaue Format, das für signierte Einbettungen erforderlich ist, hängt von der Programmiersprache ab, die zur Erstellung des Skripts für die signierte Einbettungs-URL verwendet wurde. Der Name des Nutzerattributs ist jedoch locale. Weitere Informationen zu signierten Einbettungs-URLs und den Tools für deren Erstellung finden Sie auf der Dokumentationsseite Signierte Einbettung.

Gebietsschema in Liquid-Variablen verwenden

Wie bereits beschrieben, können Sie durch Modelllokalisierung die Anzeige der Bezeichnungen und Beschreibungen Ihres Modells für verschiedene Gebietsschemata anpassen. Sie können jedoch auch Lokalisierungsschlüssel in Liquid-Variablen einfügen. Auf diese Weise können Sie auch Ihre Datenwerte lokalisieren.

In unserer Standard-Gebietsschema-Zeichenfolgendatei mit dem Namen en.strings.json können wir beispielsweise die Lokalisierungsschlüssel domestic und international mit den folgenden Einträgen erstellen:

{
  "domestic": "Domestic",
  "international": "International"
}

Anschließend können wir in unserer Datei es_ES.strings.json spanische Versionen dieser Lokalisierungsschlüssel bereitstellen: 

{
  "domestic": "Nacional",
  "international": "Internacional"
}

Nun können wir die Lokalisierungsschlüssel domestic und international in Liquid-Variablen zur Lokalisierung der Ausgabe einer Dimension verwenden:

dimension: from_US {
    label: "from_us"
    type: string
    sql: CASE
         WHEN ${TABLE}.country = 'United States' THEN '{{ _localization['domestic'] }}'
         ELSE '{{ _localization['international'] }}'
         END;;
  }

Nutzer mit dem Gebietsschema en sehen die folgenden Ergebnisse:

Flights Identifier Flights country Flights From the US?
289 United States Domestic
400 Canada International
493 Congo International
936 United States Domestic

Nutzer mit dem Gebietsschema es_ES sehen die folgenden Ergebnisse:

Vuelos Identificador Vuelos País Vuelos ¿De Los Estados Unidos?
289 United States Nacional
400 Canada Internacional
493 Congo Internacional
936 United States Nacional

Die Nutzer mit dem Gebietsschema es_ES sehen die Daten „Domestic“ und „International“ lokalisiert als „Nacional“ und „Internacional“.

Sie können Liquid auch in LookML-Dashboardfiltern und LookML-Dashboard-Elementfiltern verwenden, um den Standardwert in einem Filter zu lokalisieren. Wenn ein LookML-Dashboard beispielsweise eine Kachel mit Daten aus diesem lokalisierten Modell enthält und für diese Kachel ein Filter in LookML wie folgt definiert ist:

filters:
  flights.from_US: "{{ _localization['domestic'] }}"

Wenn ein Nutzer mit dem Gebietsschema en die Daten über diese Kachel im Dashboard analysiert, wird der Explore nach dem Wert Domestic für das Feld Flights From the US? gefiltert. Die Datentabelle im Explore enthält die folgenden Ergebnisse:

Flights Identifier Flights country Flights From the US?
289 United States Domestic
936 United States Domestic

Wenn ein Nutzer mit dem Gebietsschema es_ES die Daten über diese Kachel im Dashboard analysiert, wird der Explore nach dem Wert Nacional für das Feld Vuelos ¿De Los Estados Unidos? gefiltert. Die Datentabelle im Explore enthält die folgenden Ergebnisse:

Vuelos Identificador Vuelos País Vuelos ¿De Los Estados Unidos?
289 United States Nacional
936 United States Nacional

Auswirkungen von Lokalisierungsregeln auf erweiterte und verfeinerte Objekte

Achten Sie beim Erweitern von Ansichten, Explores oder LookML-Dashboards und beim Verfeinern von Ansichten oder Explores darauf, dass Lokalisierungsregeln gelten.

Wenn Sie ein Objekt erweitert oder verfeinert und dann neue Bezeichnungen oder Beschreibungen hinzugefügt haben, sollten Sie Lokalisierungsdefinitionen in den Gebietsschema-Zeichenfolgendateien angeben.

Beispiel: Wir haben eine Ansicht flights:


view: flights {
  label: "flight_info"
  sql_table_name: flightstats.accidents ;;
  ...
}

Anschließend erstellen wir eine neue Ansicht, die die Ansicht flights erweitert:

include: "/views/flights.view"

view: flights_enhanced {
  extends: [flights]
  label: "enhanced_flight_info"
}

In den Gebietsschema-Zeichenfolgendateien müssten wir beide Zeichenfolgen für die Ansichtsbezeichnung definieren ("flight_info" und "enhanced_flight_info"). Wenn die Lokalisierungsebene des Projekts auf strict gesetzt ist, können Aktualisierungen erst dann gespeichert werden, wenn die neuen Bezeichnungen oder Beschreibungen definiert wurden.