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 der Benutzeroberfläche.

Mit der Modelllokalisierung können Sie anpassen, wie die Labels und Beschreibungen Ihres Modells entsprechend dem Gebietsschema des Nutzers angezeigt 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 zum Lokalisieren der Looker-Benutzeroberfläche oder zum Lokalisieren von Zahlenformaten finden Sie auf den Dokumentationsseiten Unterstützte Sprachen für die Benutzeroberfläche und Lokalisierung von Zahlen.

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. Bei dieser Einstellung gibt die Looker-IDE für alle LookML-Elemente, die lokalisiert werden können, aber keine Labels haben, sowie für alle Strings in Ihrem LookML-Modell, die lokalisiert werden können, aber nicht in Ihren Locale Strings definiert sind, einen LookML-Validierungsfehler zurück.

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

Diese Werte werden in den Stringdateien mithilfe einer Lokalisierungsebene für permissive lokalisiert. Die Dimension location hat kein Label, daher können wir zeigen, 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-Paars befindet sich der Lokalisierungsschlüssel, d. h. 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. Es muss eine Stringdatei mit dem Namen der Standardsprache vorhanden sein. Wenn Sie beispielsweise default_locale: en in der Manifestdatei Ihres Projekts angegeben haben, muss die Datei en.strings.json im Modell enthalten sein. Jeder String muss in der Datei mit den standardmäßigen Gebietsschema-Strings definiert werden, sonst wird er nicht lokalisiert.

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

Hier sehen Sie eine en.strings.json-Beispieldatei, die für alle Nutzer mit dem Wert Locale von en verwendet wird. In diesem Beispiel wird auch en als Standardsprache festgelegt. Daher müssen alle Strings in dieser Datei definiert werden, um lokalisiert zu werden.

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

Das würde ein en-Nutzer in Looker sehen:

Hinweis:

  • In der oben angezeigten Datei haben wir kein Label für die Dimension location angegeben, sodass Looker den Namen der Dimension in Großbuchstaben anzeigt: &location.
  • Wir haben in der Datei en.strings.json keine Lokalisierung für das Label „country“ definiert. Daher zeigt Looker das Label so an, wie es in unserer Ansichtsdatei definiert ist, ohne es großzuschreiben: "country".

Ein weiteres Beispiel: Wir können 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 würde ein es_ES-Nutzer in Looker sehen:

Hinweis:

  • Wie im vorherigen Beispiel haben wir in der oben angezeigten Datei kein Label für die Dimension location angegeben, sodass Looker den Namen der Dimension in Großbuchstaben anzeigt: &Standort.
  • Wir haben die Lokalisierung für das Label „Land“ in unserer en.strings.json-Datei, der Standarddatei mit den Gebietsschema-Strings, nicht definiert. Obwohl wir &d;country in unserer es_ES.strings.json-Datei definiert haben, lokalisiert Looker diesen String nicht und zeigt das Label so an, wie es in unserer Ansichtsdatei definiert ist: "country".

Lokalisierungseinstellungen für Projekt werden hinzugefügt

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

Wenn Ihr Projekt noch keine Manifestdatei hat, können Sie eineüber das Symbol + oben im Dateibrowser in 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 Gebietsschema-Stringdatei 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 Beschreibungs-String definiert ist, wird in der Looker-Benutzeroberfläche der nicht lokalisierte String angezeigt, wenn dies in der Datei der standardmäßigen Gebietsschema-Strings nicht definiert ist. Weitere Informationen zum Einrichten von Gebietsschema-Stringdateien finden Sie in diesem Abschnitt.

Die Standardsprache für Ihr Projekt ist nicht mit der Standardsprache für Looker-Nutzer zu verwechseln. Ihr Looker-Administrator kann eine Standardsprache für Ihre Instanz festlegen. Wenn keine Standardeinstellung festgelegt ist, wird Looker standardmäßig auf en gesetzt. Wenn Ihr Administrator nicht explizit den Wert Locale für einen user oder eine user group angibt, der der Nutzer angehört, weist Looker den Nutzer der Standardsprache der Instanz zu. Wenn der Administrator keine Standardsprache für die Instanz festgelegt hat, weist Looker den Nutzer der Sprache en zu.

Wenn Sie nicht sicher sind, dass Ihr Looker-Administrator den Wert für Locale für alle Looker-Nutzer festlegt, sollten Sie daher den Parameter default_locale Ihres 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 für diese Sprache 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. Die Looker-IDE gibt einen LookML-Validierungsfehler für jedes dieser Elemente, die keine Labels haben, sowie für alle Labels und Beschreibungen zurück, die nicht in der Standardsprache-Stringdatei definiert sind.
  • Setzen Sie die Lokalisierungsebene auf permissive, um Elemente ohne Labels zuzulassen. Außerdem sind Labels und Beschreibungen zulässig, die nicht in der Standarddatei mit Lokalisierungsstrings definiert sind.

Selbst wenn Sie die Lokalisierungsebene strict verwenden möchten, kann es hilfreich sein, die Lokalisierungsstufe Ihres Projekts auf permissive zu setzen, wenn Sie Ihr Projekt entwickeln, um Validierungsfehler zu vermeiden. Nachdem Sie alle Labels und Beschreibungen lokalisiert haben, können Sie die Lokalisierungsebene auf strict festlegen. So werden Fehler angezeigt.

Benutzer einem Gebietsschema zuweisen

Sobald Ihre Gebietsschema-Zeichenfolgendateien eingerichtet sind, können Sie Benutzer einem Gebietsschema zuweisen, das einer Ihrer Gebietsschema-Zeichenfolgendateien entspricht. Verwenden Sie dazu das Feld Locale oder locale für das Attribut Locale, User Group oder Individual User.

Wenn ein Nutzer beispielsweise die in der Datei es_ES.strings.json definierten Labels und Beschreibungen sehen soll, sollte Ihr Looker-Administrator die Locale-Einstellung 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 Nutzer.

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. Ist für die Sprache der Instanz jedoch keine .strings-Datei eingerichtet, funktioniert die Modelllokalisierung für diese Nutzer nicht. Aus diesem Grund sollte eine .strings-Datei für jede Standardsprache der Instanz eingerichtet werden. Weitere Informationen finden Sie in den Abschnitten default_locale und Dateien mit Gebietsschema-Strings erstellen.

Gebietsschema für Benutzer von SSO-Einbettungen festlegen

Sie können den Wert des Gebietsschema eines Nutzers in eine eingebettete URL für die Einmalanmeldung wie jedes andere Nutzerattribut einfügen. Das genaue Format für SSO-Einbettungen hängt von der Programmiersprache ab, die zum Erstellen des SSO-URL-Skripts verwendet wird. Der Name des Nutzerattributs lautet jedoch locale. Weitere Informationen zu SSO-Einbettungs-URLs und Tools zum Erstellen Ihrer SSO-Einbettungs-URL finden Sie auf der Dokumentationsseite Einmalanmeldung (SSO) in der Dokumentation.

Gebietsschema in Liquid-Variablen verwenden

Wie oben beschrieben, können Sie mit der Modelllokalisierung die Darstellung der Labels und Beschreibungen Ihres Modells für verschiedene Sprachen anpassen. Sie können aber auch Lokalisierungsschlüssel in Flüssigkeitsvariablenhinzufügen. Damit können Sie auch Ihre Datenwerte lokalisieren.

In unserer standardmäßigen Locale-String-Datei 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 der Datei es_ES.strings.json können wir dann die folgenden spanischen Versionen der Lokalisierungsschlüssel bereitstellen: 

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

Von dort 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:

Und unsere Nutzer mit der Sprache es_ES sehen Folgendes:

Sie können auch „Filter“ in Filtern für Dashboard und Dashboard-Elemente 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:

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

Auswirkungen von Lokalisierungsregeln auf erweiterte und verfeinerte Objekte

Hinweis: Lokalisierungsregeln gelten, wenn Sie Ansichten, explorative Datenanalysen oder LookML-Dashboards erweitern oder wenn Sie Datenansichten oder explorative Datenanalysen verfeinern.

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

Für die Ansicht flights gilt beispielsweise:


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 Dateien mit Gebietsschema-Strings müssen wir beide Strings für Ansichtslabels ("flight_info" und "enhanced_flight_info") definieren. Wenn die Lokalisierungsstufe des Projekts auf strict gesetzt ist, können wir erst dann Aktualisierungen übernehmen, wenn wir die neuen Labels oder Beschreibungen definiert haben.