[Change] § <section> — <[Change] § 5.2, § 2.1 — Content language on properties (content_languages[], BCP 47) so language can be matched, not inferredone-line summary> #43

What kind of change?

Add a new field

Which section?

5.2 — Inventory composition

Current text

§ 5.2:
| `properties` | Object | selectable | `available[]` of `{ id, name, domains, supported_formats }`, `included[]`, `pricing`, `max_select` |

§ 2.1, Summary Representation, per line item: `line_item_id` · `channel` · `content_detail` · property names · ...

§ 4.2: `best_for[]` · Advisory planning hints. Non-normative, and never the basis for a match

Proposed text

§ 5.2, replace the properties row:
| `properties` | Object | selectable | `available[]` of `{ id, name, domains, supported_formats, content_languages[] }`, `included[]`, `pricing`, `max_select` |

Add below the § 5.2 table:
`content_languages[]` is an array of BCP 47 language tags (RFC 5646), for example `es`, `es-US`, `en`, naming the primary language(s) of the content alongside which the ad will run on that property. A seller SHOULD declare it on every property. A seller MUST list every language a property may deliver against. Where a seller can control delivery by language, it SHOULD declare separate properties per language so a buyer can select by language. The content languages of a composition are the union of `content_languages[]` across the selected properties, computable by the buyer without a round trip (§ 3).

Why

Content language is a primary buying criterion: in-language campaigns for Spanish-speaking audiences in the US are planned and budgeted as their own line in many media plans, and the same applies to French in Canada and to multilingual markets generally. A brief that says "Spanish-language video" needs a deterministic way to screen shelves by language.

Today the draft gives language nowhere to live except prose. description and specifications are free text. best_for[] is explicitly "never the basis for a match". content_detail has no defined shape. So a conforming buying agent can only infer language from prose or domain names, which is the interpretation step § 7 says the object exists to remove.

The field belongs on the property, not the line item, because properties is selectable: one line item can mix properties in different languages, and the language of the buyer's composition follows its selection (the same logic as § 3.3). OpenRTB and AdCOM already carry content language on the Content object, so this keeps discovery consistent with execution.

Knock-on effects

• § 5.2: additive sub-key on the property option, alongside the app identity being added for [Change] § 5.2 — App identity on properties (store id / bundle id) for app_mobile and ctv inventory #15 / PR § 5.2 — App identity on properties (#15) #17.
• § 2.1: summary gains the language tags so screening agents can filter without a full fetch.
• Appendix A / B: no new top-level field; marker counts unchanged.
• § 6 examples: add content_languages: ["en"] to example properties.
• [Comment] § 1, § 4.1 — brief_ref is REQUIRED for a custom proposal and points at an object the specification does not define #34 (brief): a structured brief can state required content languages using the same tags, so matching becomes a set intersection.
• Related, not proposed here: the same tags would let creative_policy state accepted creative languages if the group wants that machine-readable.
• No change to the no-inheritance rule or downstream standards.

Would this break an implementation already built to this draft?

No — additive or editorial

Alternatives you considered and rejected

• A line-item-level language field: wrong when selectable properties mix languages.
• Put language in content_detail: shape undefined, so not reliably filterable.
• Rely on best_for[] or description: non-normative / prose by design.
• Express it through audience taxonomy: an audience segment describes people, not the content the ad runs in; conflating them invites misuse.
• One line item per language with no tag: still gives the buyer agent nothing structured to filter on.

You are commenting as

Publisher / seller

Before you submit

• I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
• This contains no confidential or commercially sensitive information.