🌐 add european portuguese translation with auto language detection

[jlmcabral]

Summary

Add European Portuguese (pt) translations and auto-detect language from HA config, so users with pt-PT or pt-BR get Portuguese translations without YAML config.

Changes

• translation_languages.py — added pt section with 62 keys covering all device types (airer, vacuum, washer, dishwasher, climate, sensors, etc.)
• __init__.py — auto-detect hass.config.language when no language: is set in YAML. Tries full locale first (e.g. pt-PT), falls back to base code (pt). Benefits all languages, not just Portuguese.

Tests

Added tests/test_translation_languages.py with:

• Structural validation (all entries are dicts, no empty sub-dicts)
• Auto-detection integration tests (pt-PT, pt-BR, de, "")
• YAML language takes precedence over auto-detect

[gemini-code-assist]

Code Review

This pull request adds Portuguese (pt) translations and enhances the integration's language detection logic to support automatic fallback to base language codes (e.g., falling back to 'pt' for 'pt-PT' or 'pt-BR'). It also introduces a comprehensive test suite to verify the translation dictionaries and fallback behavior. Feedback was provided to use defensive attribute access on the Home Assistant configuration object to prevent potential AttributeErrors in minimally mocked test environments, along with a minor optimization to the language code splitting logic.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

To prevent potential AttributeError in environments where hass or hass.config might be minimally mocked (e.g., in some unit tests), we should use defensive attribute access. Additionally, we can optimize the language code fallback logic to avoid redundant splits and duplicate lookups when the language code does not contain a hyphen.

Suggested change

	elif lang := hass.config.language or '':
	parts = lang.split('-')
	for code in [lang, parts[0]]:
	dic = TRANSLATION_LANGUAGES.get(code)
	if isinstance(dic, dict):
	TRANSLATION_LANGUAGES.update(dic)
	break
	elif lang := getattr(getattr(hass, 'config', None), 'language', ''):
	codes = [lang]
	if '-' in lang:
	codes.append(lang.split('-')[0])
	for code in codes:
	dic = TRANSLATION_LANGUAGES.get(code)
	if isinstance(dic, dict):
	TRANSLATION_LANGUAGES.update(dic)
	break

[jlmcabral]

Regarding the Gemini suggestion:

• The defensive getattr is theoretically valid to prevent AttributeError in minimally mocked test environments, but in production hass.config is always present. IMO this is not critical, but I will align with the suggestion.
• The split optimization avoids a redundant dict lookup when the language code has no hyphen (e.g. pt no longer iterates ['pt', 'pt']).

[al-one]

感谢提交。这里有一个会直接影响现有用户的高优先级问题，请先解决后再合入。

风险：自动应用翻译会改变 Select/Mode 等枚举值，破坏已有自动化

PR 的实际效果是 不需要任何用户配置 就把 TRANSLATION_LANGUAGES 中的某张语言字典原地合并到模块级全局字典 ，并在 里进一步按 HA 语言展开。

合并后会改变 select / fan level / mode 等选项的实际返回值，例如：

但 select 选项值在 HA 里就是用户自动化判断的 key（条件判断、模板、、、 等）。一旦中文/英文被替换成葡萄牙语值，已有自动化、条件判断、UI 收藏夹会立即失效，需要批量改名。

我在 review 主帖里说的 “全局 module-level 字典副作用” 就是这个问题。这一行为既会污染同进程内其他用户的视图（如果有 hass.config.language 不一致的 config entry），也会影响用户对翻译可控的预期——历史行为是 必须用户在 YAML 显式配置 才会应用翻译。

建议修改方向

1. PR 不得自动应用翻译。auto-detect 只能在用户已显式配置 时作为辅助查找；不允许在没有 YAML 配置的情况下把任何语言字典合并进 。
2. 翻译命中应该在 路径内做查找，而不是修改全局字典。这样既保留向后兼容，也避免不同 hass.config.language 互相污染。
3. 测试 现在用 验证 auto-detect 生效 —— 这种行为本身就是回归。请删掉或改为验证“auto-detect 不会修改全局 TRANSLATION_LANGUAGES”。
4. miot_spec.py 里的 链式回溯应改为显式注入 hass，与本主题一并修复。

需要的话我可以帮写一版显式 注入和只在用户配置语言时才生效的查找函数。

[al-one]

感谢提交。这里有一个会直接影响现有用户的高优先级问题，请先解决后再合入。

风险：自动应用翻译会改变 Select/Mode 等枚举值，破坏已有自动化

PR 的实际效果是不需要任何用户配置就把 TRANSLATION_LANGUAGES 中的某张语言字典原地合并到模块级全局字典，并在 MiotSpec.translations 里进一步按 HA 语言展开。

合并后会改变 select / fan level / mode 等选项的实际返回值，例如：

• fan_level.low -> Baixo / Silencioso / Turbo 等
• mode.auto -> Automático
• sweep.suction_state 中的标准 / 强劲
• vacuum.mode 中的 Aspirar / Limpar

但 select 选项值在 HA 里就是用户自动化判断的 key（条件判断、模板、input_select、data_template、trigger.id 等）。一旦英文/中文键被替换成葡萄牙语值，已有自动化、条件判断、UI 收藏夹会立即失效，需要批量改名。

我在 review 主帖里说的 “全局 module-level 字典副作用” 就是这个问题。这一行为既会污染同进程内其他用户的视图（如果 hass.config.language 不一致的 config entry 共存），也会破坏用户对翻译可控的预期 —— 历史行为是必须用户在 YAML 显式配置 language: 才会应用翻译。

建议修改方向

1. PR 不得自动应用翻译。auto-detect 只能在用户已显式配置 language: 时作为辅助查找；不允许在没有 YAML 配置的情况下把任何语言字典合并进 TRANSLATION_LANGUAGES。
2. 翻译命中应该在 MiotSpec.translations 路径内做查找，而不是修改全局字典。这样既保留向后兼容，也避免不同 hass.config.language 互相污染。
3. 测试 test_auto_detect_* 现在用 async_reload_integration_config(hass, {}) 验证 auto-detect 生效 —— 这种行为本身就是回归。请删掉或改为验证 auto-detect 不会修改全局 TRANSLATION_LANGUAGES。
4. miot_spec.py 里的 obj = self; while hasattr(obj, 'service') ... 链式回溯应改为显式注入 hass，与本主题一并修复。

需要的话我可以帮写一版显式 hass 注入和只在用户配置语言时才生效的查找函数。

Submitted twice by mistake; the CHANGES_REQUESTED comment at review 4727368064 is the authoritative one.