Language & Localization Best Practices in EMA 1.7.2 avails

Submitting avails for a title for specific languages and localization type rights

Language and Localization best practices differ between Movies & TV avails. Please refer to the appropriate sections below for details.

Movies

Languages and Localization

AssetLanguages

When necessary, title language rights should be communicated in the optional columns  AllowedLanguages (to specify languages to publish) or HoldbackLanguage (when languages should be excluded or have a different release schedule). See the linked articles for more information.

The AssetLanguage column should NOT be populated in the EMA 1.7 avail for Movies unless otherwise requested by your Google operations contact. In that case please leave this blank for all new Movie titles.

HoldbackLanguage should only be used for multilingual titles. If only one language is available this field must remain empty to ensure title can go live.

Please reference the column header articles linked in  EMA 1.7 Template Headers for Movies for more information on movie avails.

Localization Types (sub, dub)

The LocalizationType column should no longer be populated in the EMA avail for Movies.  Please leave this column blank for all new Movie titles. 

Localization type availability may be specified with the AllowedLanguages or HoldbackLanguage columns.

Google will offer all audio and subtitle tracks as they are made available (delivered and QC-approved) to Google.

TV 

TV Languages and Localization

The AssetLanguage and LocalizationType columns are used for TV avails. Please reference the column header articles linked in  EMA 1.7 Template Headers for TV for more information.

Best practices

 Allowed / Holdback Languages​

  • These columns are Optional. If left blank, ALL language assets made available to Google will be published to the store.

​Localization Type and AllowedLanguages in the Avail

As part of the transition to EMA Avails 1.7.2, Google TV has asked partners to copy and paste the AltID data from their current 1.6 avail into the ALID and ContentID fields in their 1.7.2 avail.


In the event that a single AltID has more than one localization in the same territory, i.e. EN sub line items and FR dub line items in CA, we will treat as one avail (as illustrated in Table 2 below), resulting in a single offering.

Allow same ALID for sub and dub avail line items, then treat as a consolidated avail as illustrated in Table 2.

  1. When the studio redelivers in component form, they can consolidate the two avails into one and omit LocalizationType; resulting in a single offering with multiple audio and subtitle options.

  2. The studio can then submit a Full Extract avail with the consolidated set of avail line items and AllowedLanguages populated with the same ALIDs.

  3. Lastly, the studio shall deliver an MMC/MEC with corresponding ALIDs.

​ check_box HTML Validation: No errors detected Draft Source code mode Owner

ALID Approach

There are two types of implementations for ALID, Explicit vs. Implicit

Explicit Approach (Preferred)

  • ALID is constructed in a way that is explicit, meaning it is the ONLY value partners need to directly identify the experience in the MMC. 

  • ALID to Experience is 1:1 or many-to-one

  • New ALIDs required for:

    • Editorial edit 

    •  Regional edit

  • One EIDR to ALID

Implicit Approach (Supported)

  • Constructs ALID in a more implicit way, requiring more information to identify the experience, including:

    • Territory (Avail)

    • Region Tags (MMC)​

  • ALID to Experience is one-to-many

  • New ALIDs required for:

    • Editorial edit

  • ​​Presumption of EIDR update in Avail when Regional Edits created

  ​

Avail versus Manifest Collisions​
In any scenario where information in the avail conflicts and contradicts information in the MMC/MEC, the avail shall be considered the source of truth.

Related Articles

 

 

Search
Clear search
Close search
Main menu
12464372970019038943
true
Search Help Center
true
true
true
true
true
412049
false
false