LookML-Modell lokalisieren

Durch Lokalisierung des Modells 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 Labels, Gruppenlabels 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. Die Anzeige für verschiedene Nutzer durch Zuweisen von Nutzern zu Gebietsschemata festlegen.

Die Modelllokalisierung erfolgt häufig in Verbindung mit einem Administrator, der die Einstellungen für die Lokalisierung von Zahlenformaten und die Sprache der Benutzeroberfläche festlegt.

Labels 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, setzen Sie die Lokalisierungsebene Ihres Projekts auf strict. Bei dieser Einstellung gibt die Looker IDE einen LookML-Validierungsfehler für alle LookML-Elemente zurück, die lokalisiert werden können, aber keine Labels haben, sowie für alle Zeichenfolgen in Ihrem LookML-Modell, die lokalisiert werden können, aber nicht in Ihren Gebietsschema-Zeichenfolgendateien definiert sind.

In der folgenden Beispiel-LookML-Datei sind Labels für die Ansicht flights und die Felder id, country und number_of_engines angegeben. Für das Feld country wird auch eine Beschreibung bereitgestellt.

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 werden diese Werte in den Strings-Dateien mit einer permissive-Lokalisierungsebene lokalisiert. Sie sehen, dass die Dimension location nicht über eine Bezeichnung verfügt, damit wir demonstrieren können, wie eine Dimension ohne Lokalisierung angezeigt wird.

Gebietsschema-Zeichenfolgendateien erstellen

Die Gebietsschema-Zeichenfolgendaten definieren mithilfe von Schlüssel/Wert-Paaren, wie die Labels 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. Auf der rechten Seite des Schlüssel/Wert-Paares legen Sie fest, wie dieser String in der Looker-Benutzeroberfläche angezeigt werden soll.

Sie müssen für jedes Gebietsschema, das Sie für Ihr Projekt verwenden möchten, eine eigene Zeichenfolgendatei erstellen. Erstellen Sie nur eine Zeichenfolgendatei für jedes Gebietsschema. Es muss eine Zeichenfolgendatei vorhanden sein, deren Name dem Standardgebietsschema entspricht. 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 Gebietsschema-Zeichenfolgendatei default definiert sein. Andernfalls wird sie nicht lokalisiert.

Dieses Beispiel für eine en.strings.json-Datei wird für alle Nutzer verwendet, deren Gebietsschema-Wert en lautet. In der folgenden Beispiel-LookML-Datei ist en außerdem als Standard-Gebietsschema 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 der Landessprache 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:

  • In der zuvor gezeigten flights-Beispiel-LookML-Ansicht haben wir für die Dimension location keine Bezeichnung angegeben. Daher wird der Name der Dimension in Looker mit großem Anfangsbuchstaben angezeigt: „Ort“.
  • In unserer en.strings.json-Datei haben wir keine Lokalisierung für die Bezeichnung „country“ festgelegt. Daher zeigt Looker die Bezeichnung so an, wie sie in unserer Ansichtsdatei definiert ist, ohne großen Anfangsbuchstaben: „country“.

Ein weiteres Beispiel: Wir können eine es_ES.strings.json-Datei erstellen, die für alle Nutzer mit dem Wert es_ES für Locale 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 sieht:

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 haben wir in der ursprünglichen Ansicht mit hinzugefügten Labels und Beschreibungen für die Dimension location kein Label angegeben. Daher wird in Looker der Name der Dimension mit großem Anfangsbuchstaben angezeigt: „Standort“.
  • In unserer en.strings.json-Datei, der Standard-Gebietsschema-Zeichenfolgendatei, haben wir keine Lokalisierung für das Label „country“ festgelegt. Das heißt, obwohl wir „country“ in unserer es_ES.strings.json-Datei definiert haben, lokalisiert Looker diese Zeichenfolge nicht und zeigt die Bezeichnung wie in unserer 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 Ihres Projekts den Parameter localization_settings 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 in nicht in der Standard-Gebietsschema-Zeichenfolgendatei definiert ist.

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

Wenn Sie sich nicht sicher sind, dass Ihr Looker-Administrator den Wert Locale für alle Looker-Nutzer festlegt, sollten Sie den default_locale-Parameter Ihres Projekts auf das Standard-Gebietsschema für Ihre Instanz festlegen (oder auf en, wenn kein Standard festgelegt wurde) und die Lokalisierung für alle Labels und Beschreibungen in der .strings.json-Datei für dieses Gebietsschema definieren.

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, wenn Bezeichnungen für alle Modelle, Explores, Ansichten und Felder in Ihrem Projekt lokalisiert sein sollen. Wenn diese Elemente keine Labels haben, gibt die Looker IDE einen LookML-Validierungsfehler zurück. Dasselbe gilt für Labels und Beschreibungen, die in der Standard-Gebietsschema-Zeichenfolgendatei nicht definiert sind.
  • Legen Sie die Lokalisierungsebene auf permissive fest, um Elemente ohne Bezeichnungen sowie Bezeichnungen und Beschreibungen zuzulassen, die nicht in der Standard-Gebietsschema-Zeichenfolgendatei definiert sind.

Selbst wenn Sie die Lokalisierungsebene auf strict setzen möchten, könnte es praktisch sein, sie während der Entwicklung Ihres Projekts 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 etwaige Fehler festzustellen.

Nutzern ein Gebietsschema zuweisen

Sobald Ihre Gebietsschema-Zeichenfolgendateien eingerichtet sind, können Sie Benutzer einem Gebietsschema zuweisen, das einer Ihrer Gebietsschema-Zeichenfolgendateien entspricht. Das ist auf Ebene der Instanz, der Nutzergruppe oder des einzelnen Nutzers möglich. Verwenden Sie dazu das Feld Locale oder das Benutzerattribut locale.

Wenn ein Nutzer beispielsweise die in der Datei es_ES.strings.json definierten Labels und Beschreibungen sehen soll, muss der Looker-Administrator die Einstellung für die Sprache des Nutzers auf es_ES festlegen.

Benutzerdefinierte Gebietsschemata, die Sie mit der Zeichenfolgendatei erstellen, können in das Feld Locale übernommen werden. Klicken Sie hierzu auf das Feld und geben Sie den Dateinamen der Zeichenfolge ein anstatt ein integriertes Gebietsschema aus dem Dropdown-Menü auszuwählen. Weitere Informationen finden Sie auf der Dokumentationsseite Nutzer.

Gebietsschema für angemeldete Nutzer von Einbettungen festlegen

Wie jedes andere Benutzerattribut 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 signierten Einbettungs-URL-Scripts verwendet wurde. Der Name des Benutzerattributs ist jedoch locale. Weitere Informationen zu signierten Einbettungs-URLs und Tools für deren Erstellung finden Sie auf der Dokumentationsseite Signiertes Einbetten.

Gebietsschema in Liquid-Variablen verwenden

Wie bereits beschrieben, können Sie durch Lokalisierung des Modells die Anzeige der Labels 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 der Zeichenfolgendatei für das Standard-Gebietsschema 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 es_ES.strings.json-Datei 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

Nutzer mit dem Gebietsschema es_ES sehen die Daten „National“ und „International“ in den lokalisierten Versionen „Nacional“ und „Internacional“.

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

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

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

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

Wenn ein Nutzer mit der Sprache es_ES über diese Kachel im Dashboard explorative Datenanalysen durchführt, wird das Explore nach dem Wert Nacional für das Feld Vuelos ¿De Los Estados Unidos? gefiltert. Die Datentabelle im Explore enthält dann 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

Lokalisierungsregeln gelten, wenn Sie Ansichten, Explores oder LookML-Dashboards erweitern und wenn Sie Ansichten oder Explores optimieren.

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 für eine flights-Ansicht:


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 festgelegt ist, können wir keine Änderungen festschreiben, bis wir die neuen Labels oder Beschreibungen definiert haben.