WMO: multilingual CAP bodies fall through to infos[0] — no language selection

[MF-142]

Description

🐛 Bug Description / 问题描述

EN: When a user configures zh-Hans as their preferred language but the CAP XML <info> blocks use zh-CN, the provider fails to match the correct language block. This is because _select_info(), _select_region_info(), and _merge_languages() in providers/eccc.py all use strict string equality (==) for language comparison, with no BCP 47 prefix-based fallback. The same issue applies to any other BCP 47 variant pair (e.g., en-GB vs en-US, pt-BR vs pt-PT).

CN: 当用户配置首选语言为 zh-Hans，而 CAP XML 的 <info> 块使用 zh-CN 时，provider 无法正确匹配对应的语言块。原因是 providers/eccc.py 中的 _select_info()、_select_region_info() 和 _merge_languages() 均使用严格字符串相等（==）进行语言比较，没有基于 BCP 47 前缀的回退机制。同样的问题也适用于其他 BCP 47 变体对（如 en-GB vs en-US、pt-BR vs pt-PT）。

🔍 Root Cause Analysis / 根因分析

EN: Verified across all three relevant files:

File	Language Logic	BCP 47 Fallback
providers/cap.py	Pure parser; stores all <info> blocks unconditionally	❌ None
coordinator.py	Resolves "auto" → concrete code, then passes through	❌ None
providers/eccc.py	Strict == comparison; falls back to first <info> on miss	❌ None

When no exact match is found, the current fallback silently returns doc.infos[0], which may be in an entirely different language depending on XML document order.

CN: 经三个相关文件验证：

文件	语言逻辑	BCP 47 回退
providers/cap.py	纯解析器；无条件存储所有 <info> 块	❌ 无
coordinator.py	将 "auto" 解析为具体代码后透传	❌ 无
providers/eccc.py	严格 == 比较；未命中时回退到第一个 <info>	❌ 无

当没有精确匹配时，当前的回退逻辑会静默返回 doc.infos[0]，这可能是完全不同的语言，具体取决于 XML 文档中 <info> 块的排列顺序。

💡 Suggested Fix / 建议修复方案

EN: Add a helper function in providers/eccc.py that implements BCP 47 primary-subtag prefix matching, and replace all info.language == language comparisons with it:

def _language_matches(info_lang: str, preferred: str) -> bool:
    """Check language match with BCP 47 prefix fallback."""
    if not info_lang or not preferred:
        return False
    if info_lang == preferred:
        return True
    # Compare primary subtags: zh-Hans ↔ zh-CN, en-GB ↔ en-US, etc.
    return (
        "-" in preferred
        and "-" in info_lang
        and preferred.split("-", 1)[0].casefold() == info_lang.split("-", 1)[0].casefold()
    )

Then update the three call sites:

• _select_info(): if _language_matches(info.language, language)
• _select_region_info(): [info for info in doc.infos if _language_matches(info.language, language)]
• _merge_languages(): if _language_matches(v.language, preferred_lang)

CN: 建议在 providers/eccc.py 中添加一个实现 BCP 47 主子标签前缀匹配的辅助函数，并将所有 info.language == language 比较替换为该函数：

def _language_matches(info_lang: str, preferred: str) -> bool:
    """检查语言匹配，支持 BCP 47 前缀回退。"""
    if not info_lang or not preferred:
        return False
    if info_lang == preferred:
        return True
    # 比较主子标签：zh-Hans ↔ zh-CN、en-GB ↔ en-US 等
    return (
        "-" in preferred
        and "-" in info_lang
        and preferred.split("-", 1)[0].casefold() == info_lang.split("-", 1)[0].casefold()
    )

然后更新三处调用点：

• _select_info()：if _language_matches(info.language, language)
• _select_region_info()：[info for info in doc.infos if _language_matches(info.language, language)]
• _merge_languages()：if _language_matches(v.language, preferred_lang)

⚠️ Impact / 影响范围

EN: Any user whose Home Assistant language setting does not exactly match the CAP XML <language> tag will receive alerts in an unpredictable language. This affects all non-English/French ECCC users and potentially MeteoAlarm users with regional locale variants.

CN: 任何 Home Assistant 语言设置与 CAP XML <language> 标签不完全一致的用户，都将收到不可预测语言的预警信息。这影响所有非英语/法语的 ECCC 用户，以及可能使用区域变体的 MeteoAlarm 用户。

🏷️ Labels / 标签建议

bug, i18n, language-matching

Integration Version

0.1.1

Home Assistant Version

Core 2026.7.4 Supervisor 2026.07.3 Operating System 18.1 Frontend 20260624.6

Provider

WMO (rest of world)

Location Mode & Value

No response

Integration Configuration

Home Assistant Logs

[seevee]

Thanks for the detailed writeup, and for the zh-Hans translation in #58, which is now merged.

I went through this and I don't think the reported path is reachable. There are two separate language settings here, and I think the report conflates them:

• UI language comes from your Home Assistant locale and is served by translations/*.json. That is what feat(translations): add Simplified Chinese (zh-Hans) #58 added.
• Alert content language is the language option on the config entry. It selects which <cap:info> block to read out of the document the provider publishes.

The second one is worth being explicit about, because it is the root of the confusion. This integration is a passthrough for whatever data the provider actually supplies. It picks among the language blocks present in the CAP document and normalizes the structure around them. It does not translate the alert text, and it will not be adding machine translation: the wording of an emergency warning is chosen deliberately by the issuing authority, and a mistranslated instruction is a safety problem rather than a cosmetic one.

So setting the UI to zh-Hans cannot produce Chinese alert text from a feed that carries only English and French, no matter how the language matching is written.

What the Canadian feed actually carries

Rather than ask you to take that on trust, here is the whole feed in one request, standard library only:

import collections, time, urllib.request, xml.etree.ElementTree as ET

URL = "https://rss.alertready.ca/"

def fetch():  # ~7 MB, chunked, no Content-Length: truncates intermittently
    for _ in range(5):
        req = urllib.request.Request(URL, headers={"User-Agent": "naad-lang-probe"})
        body = urllib.request.urlopen(req, timeout=90).read()
        if body.rstrip().endswith(b"</feed>"):
            return body
        time.sleep(0.5)
    raise SystemExit("feed truncated on every attempt, try again")

feed = ET.fromstring(fetch())
print(collections.Counter(
    c.get("term", "").split("=", 1)[1]
    for c in feed.iter("{http://www.w3.org/2005/Atom}category")
    if c.get("term", "").startswith("language=")
))

Running it just now:

Counter({'en-CA': 622, 'fr-CA': 616})

That is every entry in the feed rather than a sample. The two counts sum to the full entry count, so nothing is unaccounted for. Your numbers will differ from mine because alerts expire continuously; the set of keys is the part that matters. The retry loop is not incidental, by the way: that endpoint serves a chunked body with no Content-Length and truncates often enough that a plain urlopen().read() fails maybe half the time.

I also pulled 25 of the 489 CAP documents those entries point at and checked <language> on every <info> block: 35 en-CA, 35 fr-CA, nothing else. The bodies are what the integration actually reads, and they agree with the envelope.

There is no zh-CN block in this feed, so no matching rule can select one.

Why the code path is unreachable

1. config_flow.py restricts the ECCC language option to vol.In(["auto", "en-CA", "fr-CA"]), so zh-Hans cannot be configured.
2. auto resolves in coordinator.py to "fr-CA" if hass.config.language.startswith("fr") else "en-CA". A zh-Hans Home Assistant install gets en-CA.
3. The feed carries only the two languages measured above.

So preferred_lang reaching eccc.py is always en-CA or fr-CA, and it matches one of the two blocks exactly.

The other two providers

• MeteoAlarm already does prefix matching. _select_info in providers/meteoalarm.py matches on the 2-letter language prefix with an en fallback, and the coordinator passes a 2-letter code for that provider on purpose.
• WMO takes the first <info> by design, because SWIC sources publish one language each. This issue is filed under Provider: WMO while the analysis is entirely about eccc.py, so I want to be sure I am not missing what you actually saw.

If what you are after is Chinese-language alert content, WMO is the axis to look at rather than the matching logic. SWIC sources are single-language, and the source ID carries the language as its trailing segment (mx-smn-es, at-zamg-en). The config flow lists the live registry, so you can check whether a Chinese-language source covers your area. That would be a separate feature request, and a reasonable one.

What I would keep

There is one real thing in this report, which is why I would rather narrow it than close it outright. If a CAP body ever declared bare en instead of en-CA, today's == misses it and falls through to doc.infos[0], which can be the French block. I have not seen NAAD do that, but prefix matching would make it safe. If you want to reframe this issue as that hardening, with a test covering en against en-CA, I will take it. #60 is close to that already, but it is currently justified by the zh-CN scenario, which does not occur.

And if you did observe alerts coming out in the wrong language, that is a different bug and I would like to chase it. Could you share which provider, the value of the language option on the entry, and the language attribute on one of the alert entities that was wrong?

[MF-142]

@seevee Thanks for the detailed analysis on the ECCC path. You're right that the Canadian feed carries no Chinese content, so the zh-Hans vs zh-CN mismatch is indeed unreachable there.

However, the BCP-47 fallback issue is reachable on the WMO provider, and I have a real-world CAP document to demonstrate it.

I retrieved the attached CAP XML from https://severeweather.wmo.int/ (WMO SWIC). It is a current high-temperature alert issued by the Penglai District Meteorological Observatory (China). The document contains two <info> blocks:

1. <language>en-US</language> — English headline & description
2. <language>zh-CN</language> — Chinese headline & description

What happens to a zh-Hans user today?

1. The WMO provider currently takes doc.infos[0] by design.
2. In this document, infos[0] is the en-US block.
3. A user whose Home Assistant is set to zh-Hans therefore receives the English alert text even though a Chinese block exists in the same document.

If WMO ever moves from "first block" to language-based selection, the strict == comparison in _select_info() / _merge_languages() would still fail to match zh-Hans against zh-CN, producing the exact bug described in this issue.

So while the ECCC path is safe, the underlying BCP-47 matching gap affects WMO users right now (by silently falling back to English) and will block proper language selection if WMO logic is refined later. I'd be happy to reframe this issue as a WMO-specific language-selection hardening if that helps, but the zh-CN ↔ zh-Hans mismatch is definitely a real scenario.

---

00-bbf8023969e787db9cc5e0eba577009d.xml

[MF-142]

@seevee I agree the ECCC path is safe after #60. However, the same underlying issue does affect the WMO provider today, and I have a real CAP document to demonstrate it.

The WMO code currently hard-codes infos[0] with no language awareness:

# custom_components/cap_alerts/providers/wmo.py
def _select_info(doc: CAPDoc) -> CAPInfoDoc:
    """Pick the first <info> block (WMO feeds carry one language each)."""
    return doc.infos[0] if doc.infos else CAPInfoDoc()

The docstring assumes SWIC sources publish one language each, but that assumption does not hold for all sources. I retrieved the attached CAP XML from https://severeweather.wmo.int/ (WMO SWIC). It is a live high-temperature alert from the Penglai District Meteorological Observatory (China), and it contains two <info> blocks:

Index	<language>	<headline>
infos[0]	en-US	"Penglai District Meteorological Observatory issues a red warning signal for high temperatures…"
infos[1]	zh-CN	"蓬莱区气象台变更发布高温红色预警信号[Ⅰ级/特别严重]"

What happens to a zh-Hans Home Assistant user?

1. WMO _select_info unconditionally returns doc.infos[0].
2. infos[0] is the en-US block.
3. The user receives the English alert text even though a Chinese block exists in the same document.

This is not a theoretical BCP-47 mismatch — it is a missing language-selection step in the WMO provider. The document carries Chinese content; the code simply never looks at it.

Could we extend the language-matching logic to WMO as well? The ECCC _language_matches helper (or a shared variant) would cover this, and it would also future-proof WMO against other multilingual SWIC sources.

[seevee]

Reopening: the WMO half of this report is real. Detail in the comment that follows.

[seevee]

@MF-142 You are right, and my premise was wrong. Thanks for pushing back with a document.

I claimed WMO sources publish one language each, which is why the provider takes doc.infos[0]. That is not what SWIC actually does. Your attachment is genuine — I pulled cn-cma-xx live and every document I sampled carries en-US then zh-CN, so infos[0] is the English block exactly as you describe.

Since one counterexample invalidated the premise, I swept the whole registry rather than patch around your case.

What SWIC actually publishes

For all 140 sources in https://severeweather.wmo.int/v2/json/sources.json, I fetched each source's RSS and read <language> off every <info> block in a live CAP document:

sampled ok: 110/140    multilingual bodies: 45
multilingual where infos[0] is NOT English: 25

(30 sources are unsampled: 21 RSS 404s — the known-unmirrored set — 6 empty feeds, 3 unparseable bodies.)

A sample of the first-block orderings:

at-zamg-en           de-DE -> en-GB
cn-cma-xx            en-US -> zh-CN
hk-hko-xx            en-US -> zh-HK
mo-smg-xx            zh-mo -> pt-PT -> en-US
fi-fmi-xx            fi-FI -> sv-FI -> en-GB
be-irm-en            nl-BE -> fr-BE -> en-GB -> de-DE
ch-meteoswiss-de     en -> de -> fr -> it -> rm
ca-aema-xx           en-CA -> fr-CA -> en-CA -> fr-CA

So _select_info is not selecting a source's only language. It is selecting an arbitrary one, and which one it lands on varies per source.

The bug is bigger than the one you reported

Your case is a zh-Hans user getting English. There is a worse one in the same data: at-zamg-en leads with de-DE. A user who picks the source whose ID ends in -en receives German alert text today. es-aemet-es leads with es-ES, no-met-en with no.

That also breaks two assumptions elsewhere in the code:

• config_flow.py:100 documents source IDs as {country}-{agency}-{lang}. 17 of 140 end in -xx and one ends in -marine, and as above the trailing segment does not predict the body language even when it looks like one.
• _wmo_source_label (wmo.py:134) derives the dropdown language from that same trailing segment, so the picker currently mislabels those sources.

What I am changing

The gap is not strict == versus prefix matching — WMO has no language selection at all. _select_info(doc) takes no language argument and the coordinator passes preferred_lang only to ECCC and MeteoAlarm. So this is a missing feature rather than a matching bug, which is why the ECCC hardening in #60 does not reach it.

I have reopened this and retitled it to WMO: multilingual CAP bodies fall through to infos[0] — no language selection, since the old title now describes something that exists nowhere in the tree: ECCC does primary-subtag fallback as of e248db1, and WMO has no equality check to be strict about. I dropped the Chinese half of the title rather than machine-translate a replacement — please put your own back if you want it there.

1. Give WMO a CONF_LANGUAGE option, auto resolving from hass.config.language.
2. Select the <info> block by BCP 47 lookup, not equality — match the full tag case-insensitively, then fall back to the primary subtag, then to any en* block, then to infos[0] as today. zh-Hans against zh-CN resolves on the primary-subtag step.
3. Fix the source-ID language assumption in the label and the config-flow comment.

The matcher needs to survive tags that are really in the feeds: zh-mo (lowercase region), mk-MKD (alpha-3 region), sr-Latn (script subtag), cnr, kl-GL. And ca-aema-xx emits en-CA -> fr-CA -> en-CA -> fr-CA, so duplicate blocks need a defined rule — first match wins is fine, but the test should pin it.

Your document is going in as a fixture; it is a clean two-block case with a non-Latin script. If you would like to take the PR, say so and it is yours — otherwise I will pick it up.

Two things unchanged from my last comment: this still does not machine-translate anything, it only selects among blocks the issuing authority published; and the ECCC analysis stands, since NAAD carries only en-CA/fr-CA and the config schema cannot produce zh-Hans there.

To be clear about what already shipped, since it is what closed this issue out from under your reply: #60 landed as the bare-primary-subtag hardening I asked for, so ECCC now matches en against en-CA. That was the right change and it is merged. It just does not touch WMO, which is the half of your original report I dismissed.

[MF-142]

@seevee Thanks for the detailed analysis and the invitation — the scope is much clearer now. I’ll have to pass on taking the PR myself, but I’m happy to test the fix once it lands and I can share more multilingual CAP documents from the WMO feed if they’re useful as fixtures.

Appreciate you pushing this forward!