Ihr LookML-Modell lokalisieren

Die Modelllokalisierung umfasst häufig auf die Lokalisierung der Zahlenformate und die Auswahl der Sprache für die Benutzeroberfläche. Weitere Informationen zu diesen Themen finden Sie auf den Dokumentationsseiten Lokalisierung der Zahlenformatierung und Unterstützte Sprachen für Nutzerschnittstellen.

Mit der Modelllokalisierung können Sie festlegen, wie die Labels und Beschreibungen Ihres Modells an das Gebietsschema des Nutzers angepasst werden.

Die Lokalisierung muss nicht auf dem Standort oder der Sprache basieren. 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.

Die Modelllokalisierung ist derzeit nicht mit dem Projektimport kompatibel.

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

Weitere Informationen zur Lokalisierung der Looker-Benutzeroberfläche oder zur Lokalisierung der Zahlenformatierung finden Sie auf den Seiten Unterstützte Sprachen für die Benutzeroberfläche und Lokalisierung der Zahlenformatierung.

Lokalisierte Elemente in den Modelldateien verwenden

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

Die Lokalisierung wird für dimension_group nicht unterstützt. Erstellen Sie stattdessen mit group_label und group_item_label eigene Dimensionen, die lokalisiert werden können.

Sie können in Ihrem Projekt auch lokalisierte LookML-Dashboards 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, legen Sie die Lokalisierungsstufe Ihres Projekts auf strict fest. Mit dieser Einstellung gibt die Looker-IDE einen LookML-Validierungsfehler für lokalisierte LookML-Elemente zurück, die keine Labels haben, sowie für alle Strings in Ihrem LookML-Modell, die lokalisiert werden können, aber nicht in Ihren Landestring-Dateien definiert sind.

Es folgt eine Beispieldatei mit einigen Bezeichnungen und Beschreibungen:

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

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

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

  dimension: country {
    label: "country"

    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 ;;
  }

Diese Werte werden in den Stringdateien mit einer Lokalisierungsebene von permissive lokalisiert. Die Dimension location hat kein Label, sodass wir nachvollziehen 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. Auf der linken Seite jedes Schlüssel/Wert-Paares befindet sich der Lokalisierungsschlüssel. Das ist ein Label- oder Beschreibungsstring aus Ihrem Modell. Rechts neben dem Schlüsselwertpaar definieren Sie, wie diese Zeichenfolge auf der Looker-Benutzeroberfläche angezeigt wird.

Erstellen Sie für jedes Gebietsschema, das Sie für Ihr Projekt benötigen, eine eigene Zeichenfolgendatei. Sie sollten nur eine Zeichenfolgendatei für jedes Gebietsschema in Ihrem Projekt erstellen. Eine Stringdatei muss Standardsprache entsprechen. Wenn Sie beispielsweise default_locale: en in der Manifestdatei Ihres Projekts angegeben haben, muss Ihr Modell die Datei en.strings.json haben. Jeder String muss in der Datei default mit Gebietsschemastrings definiert werden. Andernfalls wird er nicht lokalisiert.

Die Modelllokalisierung muss nicht auf dem Standort oder der Sprache basieren. Wenn Sie jedoch die Modelllokalisierung verwenden und auch das nativ lokalisierte Looker-Dashboard und die Visualisierungs-Benutzeroberfläche verwenden möchten, müssen Sie den Titel der Stringdatei mit den unterstützten Gebietsschemacodes von Looker abgleichen.

Hier ist ein Beispiel für eine en.strings.json-Datei, die für alle Nutzer mit dem Locale-Wert en verwendet wird. In diesem Beispiel wird en auch als Standardsprache angegeben. Alle Strings müssen daher in dieser Datei definiert werden, damit sie lokalisiert werden.

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

Das sieht ein en-Nutzer in Looker:

Hinweis:

  • In der Datei oben wurde für die Dimension location kein Label angegeben, sodass in Looker der Name der Dimension großgeschrieben wird: „Ort“.
  • Wir haben die Lokalisierung für das Label „Land“ in unserer en.strings.json-Datei nicht definiert. Daher zeigt Looker das Label so an, wie es in unserer Ansichtsdatei definiert ist, ohne es großzuschreiben: „Land“.

Als weiteres Beispiel können wir eine es_ES.strings.json-Datei erstellen, die für alle Nutzer mit dem Locale-Wert es_ES verwendet wird:

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

Das sieht ein es_ES-Nutzer in Looker:

Hinweis:

  • Wie im vorherigen Beispiel haben wir in der Datei oben kein Label für die Dimension location angegeben. Daher wird in Looker der Name der Dimension großgeschrieben: „Location“.
  • Wir haben die Lokalisierung für das Label „Land“ in unserer Datei en.strings.json nicht definiert. Das ist die standardmäßige Datei mit den Strings für das Gebietsschema. Obwohl wir in unserer es_ES.strings.json-Datei ein Land definiert haben, lokalisiert Looker diesen String nicht. Das Label wird so angezeigt, wie es in unserer Ansichtsdatei „country“ definiert ist.

Lokalisierungseinstellungen zur Manifestdatei Ihres Projekts hinzufügen

Fügen Sie der Manifestdatei Ihres Projekts den Parameter localization_settings hinzu, um die Lokalisierung für Ihr Projekt zu aktivieren.

Wenn Ihr Projekt noch keine Manifestdatei enthält, können Sie sie über das Symbol + oben im Dateibrowser der Looker-IDE erstellen.

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 standardmäßigen Stringstrings-Datei in Ihrem Projekt an.

Die Standard-Gebietsschema-Zeichenfolgendatei bestimmt, welche Zeichenfolgen aus Ihrem Modell lokalisiert werden. Selbst wenn in einer Datei mit einem anderen Gebietsschema-String ein Label oder eine Beschreibungsstrings definiert sind, wird in der Looker-Benutzeroberfläche der nicht lokalisierte String angezeigt, wenn dies nicht in der Datei mit den lokalen Strings definiert ist. Weitere Informationen zum Einrichten von Gebietsschema-Stringdateien finden Sie in diesem Abschnitt oben.

Die Standardsprache für Ihr Projekt darf nicht mit der Standardsprache für Looker-Nutzer verwechselt werden. Ihr Looker-Administrator kann eine Standardsprache für Ihre Instanz festlegen. Wenn kein Standardwert festgelegt ist, wird standardmäßig Looker en verwendet. Wenn Ihr Administrator keinen Locale-Wert für einen Nutzer oder eine Nutzergruppe eingibt, der der Nutzer angehört, wird er von Looker der Standardsprache der Instanz zugewiesen. Wenn der Administrator keine Standardinstanzsprache festgelegt hat, weist Looker den Nutzer der Sprache en zu.

Wenn Sie daher nicht sicher sind, dass der Looker-Administrator den Wert für Locale für alle Looker-Nutzer festlegt, sollten Sie den Parameter default_locale des Projekts auf die Standardsprache Ihrer Instanz festlegen (oder auf en, wenn keine Standardeinstellung festgelegt wurde) und die Lokalisierung für alle Labels und Beschreibungen in der Datei .strings.json festlegen.

localization_level

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

  • Legen Sie die Lokalisierungsebene auf strict fest, damit für alle Modelle, explorativen Datenanalysen, Datenansichten und Felder in Ihrem Projekt lokalisierte Labels erforderlich sind. Für alle Elemente, die keine Labels haben, sowie für Labels und Beschreibungen, die nicht in der Datei mit den standardmäßigen Sprachen definiert sind, gibt die Looker-IDE einen LookML-Validierungsfehler zurück.
  • Setzen Sie die Lokalisierungsebene auf permissive, um Elemente ohne Labels zuzulassen und um Labels und Beschreibungen zuzulassen, die nicht in der Datei mit den Standardlokalisierungsstrings definiert sind.

Selbst wenn Sie die Lokalisierungsstufe strict verwenden möchten, kann es hilfreich sein, die Lokalisierungsstufe Ihres Projekts auf permissive festzulegen, wenn Sie Ihr Projekt entwickeln, um Validierungsfehler zu vermeiden. Nachdem Sie alle Labels und Beschreibungen lokalisiert haben, können Sie die Lokalisierungsstufe 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. Sie können dies auf Instanzebene, Nutzergruppe oder einzelnem Nutzer mithilfe des Felds Landessprache oder des locale-Nutzerattributs tun.

Wenn Sie beispielsweise möchten, dass ein Nutzer die in der Datei es_ES.strings.json definierten Labels und Beschreibungen sieht, sollte Ihr Looker-Administrator die Landesversion des Nutzers auf es_ES festlegen:

Benutzerdefinierte Sprachen, die Sie mit Stringdateien erstellen, können in das Feld Locale eingegeben werden. Klicken Sie dazu auf das Feld und geben Sie den Dateinamen des Strings ein, anstatt eine integrierte Sprache aus dem Drop-down-Menü auszuwählen. Weitere Informationen finden Sie auf der Dokumentationsseite zu Nutzern.

Wenn für Benutzer auf Ebene des einzelnen Benutzers oder der Benutzergruppe kein Gebietsschema festgelegt wurde, weist Looker die Benutzer dem Gebietsschema der Instanz zu. Wenn jedoch keine .strings-Datei für die Sprache der Instanz eingerichtet ist, funktioniert die Modelllokalisierung für diese Nutzer nicht. Aus diesem Grund sollte für jede Instanz der Standardsprache eine .strings-Datei eingerichtet werden. Weitere Informationen finden Sie in den Abschnitten default_locale und Dateien mit Sprache-Strings erstellen.

Gebietsschema für Benutzer von SSO-Einbettungen festlegen

Wie bei jedem anderen Nutzerattribut können Sie den Wert für das Gebietsschema eines Nutzers auch in eine eingebettete URL mit SSO aufnehmen. Das genaue Format für SSO-Einbettungen hängt von der Programmiersprache ab, die zum Erstellen des Skripts für die SSO-Einbettungs-URL verwendet wird. Der Name des Nutzerattributs lautet jedoch locale. Weitere Informationen zu eingebetteten URLs und Tools zum Erstellen von eingebetteten SSO-URLs finden Sie auf der Dokumentationsseite Einmalanmeldung (SSO).

Gebietsschema in Liquid-Variablen verwenden

Wie oben beschrieben, können Sie mit der Modelllokalisierung die Anzeige der Labels und Beschreibungen Ihres Modells für verschiedene Sprachen anpassen. Sie können aber auch Lokalisierungsschlüssel in flüssige Variablen aufnehmen, um damit auch Ihre Datenwerte zu lokalisieren.

In unserer standardmäßigen Datei mit den Gebietsschema-Strings 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"
}

In unserer es_ES.strings.json-Datei können wir dann spanische Versionen dieser Lokalisierungsschlüssel angeben: 

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

Von dort aus können wir die Lokalisierungsschlüssel domestic und international in Liquid-Variablen verwenden, um die Ausgabe einer Dimension zu lokalisieren:

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

Unsere Nutzer mit der Sprache en sehen Folgendes:

Unsere Nutzer mit der Sprache es_ES sehen Folgendes:

Sie können auch „Flüssigkeit“ in den Filtern Dashboard und Dashboard-Element verwenden, um den Standardwert in einem Filter zu lokalisieren. Beispiel: Ein LookML-Dashboard verfügt über eine Tile aus dem Explore oben und für diese Tile ist folgender Filter definiert:

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

Nutzer mit der Sprache en sehen Folgendes, wenn sie diese Kachel auf dem Dashboard verwenden:

Im Folgenden wird gezeigt, was Nutzer mit der Sprache es_ES sehen, wenn sie diese Kachel auf dem Dashboard verwenden:

Auswirkungen von Lokalisierungsregeln auf erweiterte und verfeinerte Objekte

Beachten Sie, dass Lokalisierungsregeln gelten, wenn Sie Ansichten erweitern, explorative Datenanalysen oder LookML-Dashboards erweitern und wenn Sie Ansichten oder explorative Datenanalysen verfeinern.

Wenn Sie ein Objekt erweitert oder optimiert und dann neue Labels oder Beschreibungen hinzugefügt haben, sollten Sie Lokalisierungsdefinitionen in den Dateien für Gebietsschema-Strings angeben.

Hier ein Beispiel für eine flights-Ansicht:


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

Dann erstellen wir eine neue Ansicht, die die Ansicht flights erweitert:

include: "/views/flights.view"

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

In unseren Gebietsschema-Stringdateien müssen wir beide Ansichtslabel-Strings definieren ("flight_info" und "enhanced_flight_info"). Wenn die Lokalisierungsebene des Projekts auf strict festgelegt ist, können wir keine Aktualisierungen durchführen, bis wir die neuen Labels oder Beschreibungen definiert haben.