Ihr LookML-Modell lokalisieren

Mit der Modelllokalisierung können Sie anpassen, wie die Bezeichnungen und Beschreibungen Ihres Modells je nach Sprache des Nutzers angezeigt werden.

Eine Lokalisierung muss dabei nicht auf geografischem Standort oder 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.

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-Stringdateien erstellen.
  3. Aktivieren Sie die Lokalisierung für Ihr Projekt, indem Sie der Manifestdatei des Projekts Lokalisierungseinstellungen hinzufügen.
  4. Sie können die Anzeige für verschiedene Nutzer festlegen, indem Sie Nutzer den Sprachen zuweisen.

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

Beschriftungen und Beschreibungen im Modell lokalisieren

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

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

Im folgenden Beispiel-LookML werden Labels für die Ansicht flights und die Felder id, country und number_of_engines bereitgestellt. Das Feld country enthält auch eine Beschreibung.

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 Beispielen auf dieser Seite lokalisieren wir diese Werte in den Stringdateien mithilfe der Lokalisierungsstufe permissive. Beachten Sie, dass die Dimension location kein Label hat, sodass wir zeigen können, wie eine Dimension ohne Lokalisierung dargestellt 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. Dabei handelt es sich um einen Label- oder Beschreibungsstring 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 Stringdatei, deren Name dem Standardgebietsschema entspricht. Wenn Sie beispielsweise default_locale: en in der Manifestdatei Ihres Projekts angegeben haben, muss Ihr Modell eine Datei namens en.strings.json haben. Jeder String muss in der default-Datei mit den Gebietsschema-Strings definiert sein. Andernfalls wird er nicht lokalisiert.

Dieses Beispiel einer en.strings.json-Datei wird für alle Nutzer verwendet, deren Locale-Wert en ist. Im folgenden Beispiel-LookML wird en auch als Standardgebietsschema angegeben. Daher müssen alle Strings 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:

  • In der zuvor gezeigten flights-Beispiel-LookML-Ansicht haben wir für die Dimension location kein Label bereitgestellt. Daher wird in Looker der Name der Dimension in Großbuchstaben angezeigt: „Location“.
  • Wir haben in unserer en.strings.json-Datei keine Lokalisierung für das Label „Land“ definiert. Daher zeigt Looker das Label so an, wie es in der Ansichtsdatei definiert ist, ohne Großschreibung: „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",
  "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 der Spracheinstellung 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 haben wir in der Originalansicht mit hinzugefügten Labels und Beschreibungen kein Label für die Dimension location angegeben. Daher wird in Looker der Name der Dimension in Großbuchstaben angezeigt: „Location“.
  • In unserer en.strings.json-Datei, die unsere Standard-Gebietsschema-Stringdatei ist, haben wir keine Lokalisierung für das Label „Land“ definiert. Obwohl wir „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 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-Stringdatei in Ihrem Projekt an.

Die Standard-Gebietsschema-Zeichenfolgendatei bestimmt, welche Zeichenfolgen aus Ihrem Modell lokalisiert werden. Auch wenn ein Label- oder Beschreibungsstring in einer anderen Sprachstringdatei definiert ist, wird in der Looker-Benutzeroberfläche der nicht lokalisierte String angezeigt, wenn er nicht in der default-Gebietsschemastringdatei definiert ist.

Die Standardsprache für Ihr Projekt ist nicht zu verwechseln mit der Standardsprache für Looker-Nutzer. Ihr Looker-Administrator kann für die Instanz eine Standardsprache festlegen. Wenn keine Standardeinstellung festgelegt ist, wird Looker standardmäßig auf en gesetzt. Wenn Ihr Administrator für einen Nutzer oder eine Nutzergruppe, zu der der Nutzer gehört, keinen Wert für das Gebietsschema eingibt, weist Looker den Nutzer dem Standardgebietsschema der Instanz zu. Wenn der Administrator kein Standardgebietsschema für die Instanz festgelegt hat, weist Looker dem Nutzer außerdem das Gebietsschema en zu.

Wenn Sie nicht sicher sind, dass Ihr Looker-Administrator den Wert Locale für alle Looker-Nutzer festlegen wird, sollten Sie den default_locale-Parameter des Projekts auf die Standardsprache für Ihre Instanz (oder en, wenn kein Standard festgelegt wurde) festlegen und die Lokalisierung für alle Labels und Beschreibungen in der Datei .strings.json für dieses Gebietsschema 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 Labels für alle Modelle, Explores, Ansichten und Felder in Ihrem Projekt lokalisiert werden. Die Looker IDE gibt einen LookML-Validierungsfehler für alle diese Elemente ohne Beschriftungen sowie für alle Beschriftungen und Beschreibungen zurück, die nicht in der Standard-Gebietsschema-Zeichenfolgendatei definiert sind.
  • Legen Sie die Lokalisierungsebene auf permissive fest, um Elemente ohne Labels zuzulassen und auch Labels und Beschreibungen zuzulassen, die nicht in der Standard-Lokalisierungsstringdatei definiert sind.

Auch wenn Sie die Lokalisierungsstufe strict bevorzugen, kann es hilfreich sein, die Lokalisierungsstufe Ihres Projekts bei der Entwicklung Ihres Projekts auf permissive zu setzen, um Validierungsfehler zu vermeiden. Nachdem Sie alle Labels und Beschreibungen lokalisiert haben, können Sie die Lokalisierungsebene auf strict setzen, um eventuelle 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. Das kann auf Ebene von Instanzen, Nutzergruppen oder einzelnen Nutzern über das Feld Gebietsschema oder das Nutzerattribut locale erfolgen.

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

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

Gebietsschema für Nutzer von signierten eingebetteten Einbettungen festlegen

Sie können den Gebietsschemawert eines Nutzers wie jedes andere Nutzerattribut in eine signierte Einbettungs-URL einbeziehen. Das genaue Format, das für signierte Einbettungen erforderlich ist, hängt von der Programmiersprache ab, die zum Erstellen des Skripts für signierte Einbettungs-URLs verwendet wird. Der Name des Nutzerattributs lautet jedoch locale. Auf der Dokumentationsseite Signierte Einbettung finden Sie weitere Informationen zu signierten Einbettungs-URLs und Tools zum Erstellen signierter Einbettungs-URLs.

Gebietsschema in Liquid-Variablen verwenden

Wie bereits beschrieben, können Sie mithilfe der Modelllokalisierung die Anzeige der Bezeichnungen und Beschreibungen Ihres Modells für verschiedene Gebietsschemata anpassen. Sie können jedoch auch Lokalisierungsschlüssel in Liquid-Variablen einbinden und so auch Ihre Datenwerte lokalisieren.

In unserer standardmäßigen Sprachstringdatei namens en.strings.json können wir beispielsweise die Lokalisierungsschlüssel domestic und international mit den folgenden Einträgen erstellen:

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

Und dann können wir in unserer es_ES.strings.json-Datei spanische Versionen dieser Lokalisierungsschlüssel bereitstellen: 

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

Anschließend 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;;
  }

Nutzer mit der Sprache 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 der Sprache 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

Für Nutzer mit der Sprache es_ES werden die Daten für „Inland“ und „International“ in „Nacional“ bzw. „Internacional“ lokalisiert.

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 verfügt über eine Kachel, die Daten aus diesem lokalisierten Modell verwendet, und es gibt einen Filter für diese Kachel, der in LookML definiert ist:

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

Wenn ein Nutzer mit der Sprache en diese Kachel im Dashboard verwendet, wird das Explore nach dem Wert Domestic für das Feld Flights From the US? gefiltert und 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 der Sprache es_ES diese Kachel im Dashboard verwendet, 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

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

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

Beispiel für die Ansicht flights:


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

Und 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-Zeichenfolgendateien müssten wir beide Ansichtslabel-Strings ("flight_info" und "enhanced_flight_info") definieren. Wenn die Lokalisierungsebene des Projekts auf strict gesetzt ist, können wir keine Aktualisierungen vornehmen, bis wir die neuen Labels oder Beschreibungen definiert haben.