Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

將 LookML 模型本地化

透過模型本地化，您可以根據使用者的語言代碼，自訂模型標籤和說明顯示方式。

本地化不一定要以地理位置或語言為依據。您可以使用語言代碼代表其他區別因素，例如內部與外部使用者，或是管理員與個人貢獻者，並據此自訂標籤和說明。

本頁面說明專案本地化的步驟：

在模型中新增標籤、群組標籤和說明，決定要本地化的元素。
建立語言代碼字串檔案，為專案提供在地化定義。
在專案的資訊清單檔案中新增本地化設定，為專案啟用本地化功能。
將使用者指派給語言代碼，決定不同使用者的顯示方式。

模型本地化通常會與管理員一起進行，管理員會指定數字格式本地化和使用者介面語言設定。

在模型中本地化標籤和說明

您可以將模型中的標籤、群組標籤和說明在地化，包括：

label 欄位、模型、探索或檢視
Looker 擴充功能架構中的label應用程式
「探索」的 group_label 和「欄位」的 group_label
group_item_label 欄位
「探索」的 description 和「欄位」的 description
由 dimension_group 參數產生的時間範圍、間隔和自訂時間範圍 (詳情請參閱本頁的「本地化維度群組」一節)

您也可以在專案中建立本地化的 LookML 資訊主頁。下列 LookML 資訊主頁參數可以本地化：

title
description
text (這是 note 參數的子參數，可套用至所有資訊主頁元素類型，type: text 元素除外)
comparison_label
single_value_title

如要查看專案中所有可本地化的欄位，請將專案的本地化層級設為 strict。啟用這項設定後，如果 LookML 元素可進行本地化，但沒有標籤，或是 LookML 模型中的字串可進行本地化，但未在語言代碼字串檔案中定義，Looker IDE 就會傳回 LookML 驗證錯誤。

在下列 LookML 範例中，系統會為 flights 檢視區塊和 id、country 和 number_of_engines 欄位提供標籤。此外，我們也提供 country 欄位的說明。

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

在本頁的後續範例中，我們將使用 permissive 本地化層級，在字串檔案中本地化這些值。請注意，location 維度沒有標籤，因此我們可以示範如何顯示沒有本地化的維度。

建立區域設定字串文件

語言代碼字串檔案會使用鍵/值組合，定義模型中每個語言代碼的標籤和說明顯示方式。每個鍵/值組合的左側是本地化鍵，也就是模型中的標籤或說明字串。鍵/值組合的右側用於定義字串在 Looker 使用者介面中的顯示方式。

如要為專案使用特定語言代碼，必須建立專屬的字串檔案。每個語言代碼只能建立一個字串檔案。您必須擁有與預設語言代碼相符的字串檔案名稱。舉例來說，如果您在專案的資訊清單檔案中指定 default_locale: en，則模型中必須有名為 en.strings.json 的檔案。每個字串都必須在預設語言代碼字串檔案中定義，否則不會本地化。

如果使用者的語言代碼值為 en，系統就會使用這個 en.strings.json 檔案範例。在下列 LookML 範例中，en 也指定為預設語言代碼，因此所有字串都必須在這個檔案中定義，才能進行本地化。

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

下表顯示使用者將語言代碼設為 en 時，在 Looker 探索的資料表中會看到什麼：

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

注意事項：

在本頁稍早顯示的 flights 檢視範例 LookML 中，系統未提供 location 維度的標籤，因此 Looker 會將維度名稱大寫，並顯示為「Location」。
「country」標籤的在地化設定未在 en.strings.json 檔案中定義，因此 Looker 會顯示檢視表檔案中定義的標籤，且不會將標籤大寫：「country」。

再舉一例，我們可以建立 es_ES.strings.json 檔案，供 Locale 值為 es_ES 的所有使用者使用：

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

下表顯示語言代碼設為 es_ES 的使用者在 Looker 中看到的內容：

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

注意事項：

如上例所示，在加入標籤和說明後，原始檢視畫面並未提供位置維度的標籤，因此 Looker 會將維度名稱大寫並顯示為「Location」。
en.strings.json 檔案 (預設語言代碼字串檔案) 中未定義「country」標籤的本地化設定。也就是說，即使 es_ES.strings.json 檔案中定義了「country」，Looker 也不會將這個字串在地化，而是會顯示在檢視表檔案中定義的標籤：「country」。

在專案的資訊清單檔案中新增本地化設定

若要為您的專案啟用在地化，請將 localization_settings 參數新增至專案的資訊清單檔案。

在資訊清單檔案中新增本地化設定。範例如下：

localization_settings: {
  default_locale: en
  localization_level: permissive
}

`default_locale`

default_locale 參數會指定專案中預設語言代碼字串檔案的名稱。

預設語言代碼字串檔案會決定要從模型本地化哪些字串。即使標籤或說明字串是在其他語言代碼字串檔案中定義，如果未在預設語言代碼字串檔案中定義，Looker UI 就會顯示未本地化的字串。

請勿將專案的預設語言代碼與 Looker 使用者的預設語言代碼混淆。Looker 管理員可以為執行個體設定預設語言代碼。如果未設定預設值，Looker 會預設為 en。如果管理員未為使用者或使用者所屬的使用者群組，明確輸入 Locale 值，Looker 會將使用者指派至預設例項地區設定。如果管理員未設定預設執行個體語言代碼，Looker 會將使用者指派給 en 語言代碼。

因此，除非您確定 Looker 管理員會為所有 Looker 使用者設定「語言代碼」值，否則應將專案的 default_locale 參數設為執行個體的預設語言代碼 (如果未設定預設語言代碼，則設為 en)，並在該語言代碼的 .strings.json 檔案中，為所有標籤和說明定義本地化設定。

`localization_level`

專案的本地化層級會指定模型是否允許未本地化的元素：

將本地化層級設為 strict，要求專案中的所有模型、探索、檢視區塊和欄位都必須使用本地化標籤。如果這些元素沒有標籤，或是標籤和說明未在預設語言代碼字串檔案中定義，Looker IDE 就會傳回 LookML 驗證錯誤。
將本地化層級設為 permissive，允許沒有標籤的元素，以及未在預設本地化字串檔案中定義的標籤和說明。

即使您需要strict本地化層級，在開發專案時，將專案的本地化層級設為 permissive 也有助於避免驗證錯誤。完成所有標籤和說明的本地化作業後，您可以將本地化層級設為 strict，查看是否有任何錯誤。

將使用者指派給語言代碼

設定好地區設定字串檔案後，即可將使用者指派給與其中一個地區設定字串檔案對應的地區設定。您可以使用「Locale」欄位或 locale 使用者屬性，在執行個體、使用者群組或個別使用者層級執行這項操作。

舉例來說，如果希望使用者看到 es_ES.strings.json 檔案中定義的標籤和說明，Looker 管理員應將使用者的「語言代碼」設定設為 es_ES。

如要使用字串檔案建立自訂語言代碼，請點選「語言代碼」欄位並輸入字串檔案名稱，而非從下拉式選單選取內建語言代碼。有關更多信息，請參閱 Users 文檔頁面。

為已簽署的嵌入式使用者設定區域設置

您可以將使用者的地區設定值納入已簽署的嵌入網址，就像其他使用者屬性一樣。已簽署的嵌入內容所需格式取決於用於建構已簽署嵌入內容網址指令碼的程式設計語言，但使用者屬性的名稱為 locale。如要進一步瞭解已簽署的嵌入網址，以及用於建構已簽署嵌入網址的工具，請參閱「已簽署的嵌入」說明文件頁面。

維度群組在地化

您可以使用 dimension_group 參數進行模型本地化。LookML 開發人員可使用這項功能，為下列項目提供自訂翻譯：

type: time 維度群組的時間範圍 (例如 month、year 或標準時間範圍選項)
type: duration 維度群組的時間間隔 (例如 months、years 或標準間隔選項)
type: custom_calendar 維度群組的自訂時間範圍 (例如 custom_period 或 custom_year)。請參閱「自訂日曆維度群組的本地化」。

本地化維度群組對於自訂日曆維度群組產生的欄位提供自訂、準確的名稱尤其有用（例如，將預設欄位重新命名為「銷售期間」）。

如要翻譯或重新命名維度群組產生的時間範圍和間隔值，請在地區設定字串檔案 (例如 en.strings.json 和 es_ES.strings.json) 中，將時間範圍、間隔或自訂時間範圍字串新增為鍵，並提供翻譯後的顯示值。

以下是範例維度群組的 LookML：

  dimension_group: created {
    type: time
    timeframes: [time, date, week, month, year]
    sql: ${TABLE}.created_at ;;
  }

以下是 en.strings.json 地區設定字串檔案範例，提供 year 的鍵/值組合翻譯：

{
  "year": "translated year",
}

在「探索」的欄位挑選器中，維度群組會顯示如下：

Created Date
  Date
  Month
  Time
  translated year
  Week

自訂日曆維度群組的本地化

如果是 type: custom_calendar 維度群組，您必須在語言代碼字串檔案中加入自訂時間範圍 (例如 custom_date 和 custom_year) 做為鍵，並提供翻譯後的顯示值。

以下是自訂日曆維度群組的 LookML 範例：

  dimension_group: cust_created_localized {
    type: custom_calendar
    custom_timeframes: [custom_date, custom_week, custom_period, custom_year]
    sql: ${TABLE}.created_at ;;
    based_on_calendar: retail_custom_calendar_v2
  }

以下是 en.strings.json 地區設定字串檔案範例，提供 period 和 custom_week 的鍵/值組合翻譯：

{
  "period": "translated period",
  "custom_week": "translated custom week"
}

在「探索」挑選器中，自訂日曆維度群組會顯示如下：

Cust Created Localized
  Fiscal Date
  Fiscal Period
  Fiscal Year
  translated custom week

請注意，Looker 在「探索」選擇器中顯示自訂日曆維度群組的方式如下：

由於 en.strings.json 語言代碼字串檔案指定了 custom_week 的翻譯，因此維度群組的 custom_week 時間範圍會使用翻譯值 (「translated custom week」)，而非預設值 (「Fiscal Week」)。
en.strings.json 語言代碼字串檔案提供 period 的翻譯，但未提供 custom_period 的翻譯，因此自訂維度群組的 custom_period 時間範圍不會翻譯，而是使用預設標籤 (「會計週期」)。如要讓 Looker 翻譯 custom_period 時間範圍，字串檔案必須有專為 custom_period 提供的鍵/值組合翻譯。
其他自訂維度群組時間範圍不會翻譯。而是會加上「會計」前置字串，詳情請參閱「自訂日曆維度群組的標籤」。

在 Liquid 變數中使用語言代碼

如前所述，模型本地化可讓您針對不同的語言環境自訂模型的標籤和描述的顯示。但您也可以在 Liquid 變數中加入本地化鍵，這樣就能本地化資料值。

例如，在名為 en.strings.json 的預設區域設定字串檔案中，我們可以使用以下條目建立本地化鍵 domestic 和 international：

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

接著，我們可以在 es_ES.strings.json 檔案中提供這些本地化鍵的西班牙文版本：

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

接著，我們可以在 Liquid 變數中使用 domestic 和 international 本地化鍵，將維度的輸出內容本地化：

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

使用 en 語言地區的使用者會看到以下結果：

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

使用 es_ES 語言地區的使用者會看到以下結果：

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

如果使用者採用 es_ES 地區設定，系統會將「國內」和「國際」資料分別翻譯為「Nacional」和「Internacional」。

您也可以在 LookML 資訊主頁篩選器和 LookML 資訊主頁元素篩選器中使用 Liquid，將篩選器的預設值本地化。例如，如果 LookML 資訊主頁中有一個使用此在地化模型的資料的圖塊，而 LookML 中為該圖塊定義瞭如下篩選器：

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

如果使用者在資訊主頁的該動態磚上探索 en 地區設定，系統會根據 Flights From the US? 欄位的 Domestic 值篩選探索結果，且探索中的資料表會包含下列結果：

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

當具有 es_ES 語言環境的使用者從儀表板上的該磁貼進行瀏覽時，「瀏覽」將根據 Vuelos ¿De Los Estados Unidos? 欄位的值 Nacional 進行篩選，「瀏覽」中的資料表將包含以下結果：

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

瞭解本地化規則如何套用至擴充和精細物件

請注意，擴充檢視區塊、探索或 LookML 資訊主頁，以及調整檢視區塊或探索時，系統會套用本地化規則。

如果您擴充或改良物件，然後新增標籤或說明，則應在語言代碼字串檔案中提供本地化定義。

舉例來說，如果我們有 flights 檢視畫面：


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

接著，我們建立擴充 flights 檢視區塊的新檢視區塊：

include: "/views/flights.view"

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

在我們的本地化字串檔案中，我們需要定義視圖標籤字串（"flight_info" 和 "enhanced_flight_info"）。如果專案的本地化等級設定為 strict，那麼在定義新的標籤或描述之前，我們將無法提交任何更新。

模型本地化和專案導入

在匯入其他專案的專案中，您可以使用模型本地化功能。如果匯入專案有地區設定定義，Looker 預設只會使用匯入專案的地區設定定義。不過，如要將匯入專案的語言代碼定義與匯入專案的語言代碼定義合併，可以在匯入專案資訊清單 (manifest.lkml) 檔案的 localization_settings 參數中新增 import_locale_defs: yes 陳述式：

project_name: "my_project"

localization_settings: {
  default_locale: en
  localization_level: permissive
  import_locale_defs: yes
}

如果 import_locale_defs 設為 yes，Looker 會合併每個專案中對應各語言代碼的字串檔案。

重複鍵的優先順序規則

如果匯入專案和匯入專案中，不同的字串檔案都定義了相同的鍵，Looker 會在合併地區設定定義時套用下列優先順序規則：

匯入專案鍵優先：匯入專案語言代碼檔案中定義的鍵，一律會覆寫任何匯入專案語言代碼檔案中的重複鍵。
匯入順序決定優先順序：如果重複的鍵只存在於匯入專案的語言代碼檔案中，Looker 會根據專案在匯入專案資訊清單檔案中的匯入順序，解決衝突。資訊清單檔案中稍後匯入的專案，其鍵/值定義會優先於先前匯入的專案。
使用匯入專案的設定：所有合併檔案都會使用匯入專案的本地化設定 (例如 default_locale 和 localization_level)，並覆寫匯入專案資訊清單檔案中定義的任何本地化設定。