Translations update from Hosted Weblate

[weblate]

Translations update from Hosted Weblate for OpenWrt/LuCI/modules/luci-base.

Current translation status:

[openwrt-ai]

Automated review of the 1 new commit (ca31ab8).

Checked all 48 .po files for printf/%{...} placeholder drift, HTML tag mismatches, plural-form count vs. header nplurals, and stray fuzzy flags. No placeholder or plural-form regressions are introduced by this batch — the %s mismatches in https-dns-proxy/po/ru and package-manager/po/ru and the %{...} drift in firewall/po/ru all pre-date this PR and are untouched here. Five inline notes below, mostly on the Czech strings and on the newly added stub files.

---

Generated by Claude Code

[openwrt-ai]

Mistranslated: Nejvyšší teplota means "highest temperature", but this string is an alarm/warning condition label, not a measured maximum. It comes from the L map in statusLabel() at sfp-info/main.js:170-184,`` where temp_high is rendered as a `label notice` badge meaning "the temperature is high". The Russian translation added in this same commit gets it right — `sfp-info/po/ru/sfp-info.po:97` uses `Высокая температура` ("high temperature"), not a superlative.

Suggested change

	msgstr "Nejvyšší teplota"
	msgstr "Vysoká teplota"

The same superlative-vs-condition problem applies to three more entries in this file: line 99 Nejnižší teplota → Nízká teplota, line 115 Nejvyšší napětí → Vysoké napětí, line 119 Nejnižší napětí → Nízké napětí.

---

Generated by Claude Code

[openwrt-ai]

nit: gender/number agreement is inconsistent with the pre-existing entry in the same file — qosify/po/cs/qosify.po:133 translates Config saved as Nastavení uloženo (neuter singular). Both strings are notification texts for the same save flow, so they should read the same way.

Suggested change

	msgstr "Nastavení uložena"
	msgstr "Nastavení uloženo"

---

Generated by Claude Code

[openwrt-ai]

nit: is Pracující the intended register here? This string is not a status adjective — it is the title of the progress modal opened by svcAction() at qosify/main.js:888,`` shown above the body text "Sending %s to qosify...". Pracující reads as the participle/noun "a working (person)"; a progress-modal heading would normally be phrased as an ongoing action (e.g. `Pracuji…` / `Probíhá zpracování…`), matching the other in-progress strings in this file such as `Ukládání` (line 535) and `Nahrávání` (line 617).

---

Generated by Claude Code

[openwrt-ai]

This file is a 100%-untranslated stub — all 68 msgstr entries are empty and Last-Translator is still Automatically generated. Adding it has a build-system side effect beyond tree bloat: LUCI_LANGUAGES is derived from $(wildcard ${CURDIR}/po/*) at luci.mk:10, so creating po/sv/ alone generates a new luci-i18n-chrony-sv package. Its install rule at luci.mk:345-352 writes a uci-defaults script that registers luci.languages.sv, i.e. it adds Swedish to the LuCI language selector while shipping an empty .lmo.

Five other new stub files in this PR are in the same state (every msgstr empty):

• applications/luci-app-qosify/po/zh_Hant/qosify.po (166 strings)
• applications/luci-app-sfp-info/po/es/sfp-info.po (29 strings)
• applications/luci-app-sfp-info/po/ko/sfp-info.po (29 strings)
• applications/luci-app-sfp-info/po/lt/sfp-info.po (29 strings)
• applications/luci-app-sfp-info/po/uk/sfp-info.po (29 strings)

Together that is ~1500 added lines producing no translated string. Would it be reasonable to have Weblate hold these back until they carry at least some content, or drop them from this batch?

---

Generated by Claude Code

[openwrt-ai]

nit: luci-app-https-dns-proxy is maintained out of tree at https://github.com/mossdef-org/luci-app-https-dns-proxy, so translation work for it should land there rather than in openwrt/luci (same reasoning as PRs #8462 and #8625). Weblate still appears to be syncing this component against this repo — worth unhooking it from the OpenWrt/LuCI Weblate project so these edits don't diverge from upstream.

---

Generated by Claude Code

[openwrt-ai]

Re-review after the force-push: the previously reviewed commit ca31ab8 was replaced by 997c14a8, so this covers git diff ca31ab8..997c14a8 — 22 .po files, mostly newly filled-in Czech and Spanish strings plus six new language directories.

Re-ran the mechanical checks over every entry whose msgstr changed in this range: no printf/%{...} placeholder drift, no HTML tag mismatches, no msgstr[n] count vs. header nplurals mismatches, no stray fuzzy flags, no leading/trailing whitespace divergence. The %s-carrying strings newly translated in qosify/po/cs (Save failed: %s, Sending %s to qosify..., Unknown class/DSCP target: %s, nat only reaches %s — …, etc.) all preserve their placeholders.

What is left is semantic, and concentrated in the Czech qosify strings, where three of the new translations invert or misstate the meaning of a diagnostic — one names the wrong UCI option, two flip a condition. Those are worth fixing before merge since the strings exist specifically to tell users which key to set. The rest are inline nits: the Czech sfp-info alarm labels repeat the superlative-vs-condition pattern already raised on the previous head, and the six newly added stub language files extend the empty-.lmo packaging concern from the last round.

The earlier notes on sfp-info/po/cs (temperature/voltage), qosify/po/cs (Config saved, Working) and luci-app-https-dns-proxy being maintained out of tree are unchanged by this push and still apply.

---

Generated by Claude Code

[openwrt-ai]

Wrong UCI option name: the source string names bandwidth_up, the translation says bandwidth_down. It looks copy-pasted from the ingress entry three lines above (line 702), which correctly says bandwidth_down. The two warnings come from adjacent branches in ifLint() at qosify/main.js:118-119`` — c.egress && !c.bw_up vs `c.ingress && !c.bw_dn` — so a Czech user hitting the egress warning would be pointed at the wrong option to set.

Suggested change

	msgstr "žádné bandwidth_down nebo bandwidth – výstupní CAKE běží neomezované"
	msgstr "žádné bandwidth_up nebo bandwidth – výstupní CAKE běží neomezované"

---

Generated by Claude Code

[openwrt-ai]

Negation inverted: the source says "CAKE does accept flows plus nat", the translation says CAKE nepřijímá toky plus nat ("CAKE does not accept"). The whole point of the hint — emitted by ifLint() at qosify/main.js:113`` when nat=1 but no `nat` token reaches CAKE — is that the combination is valid, so the user should add `nat` to `options`. As translated it tells the reader the opposite while still telling them to do it.

Suggested change

	"CAKE nepřijímá toky plus nat – pro jeho uplatnění dejte do předvoleb nat"
	"CAKE přijímá toky plus nat – pro jeho uplatnění dejte nat do předvoleb"

---

Generated by Claude Code

[openwrt-ai]

Condition inverted: unless is rendered as pokud ("if"), so the Czech reads "are ignored if overhead_type is manual" — the exact opposite of the source. The warning is only pushed when s.overhead_type !== 'manual', see qosify/main.js:116,`` i.e. manual is the value that makes the two keys take effect. The other string in this file that states the same rule gets it right (line 683: `overhead a overhead_encap je uplatňováno pouze pokud overhead_type je manual`), so the two currently contradict each other.

Suggested change

	msgstr "overhead a overhead_encap jsou ignorovány pokud overhead_type je manual"
	msgstr ""
	"overhead a overhead_encap jsou ignorovány, pokud overhead_type není manual"

---

Generated by Claude Code

[openwrt-ai]

nit: Napravte to means "fix it", but the source instruction is "Start" — the concrete action of starting the qosify service from the Overview tab. This is the alert-message warning shown when !ctx.running at qosify/main.js:876,`` where the Overview tab offers a literal Start button (Spustit, line 583 of this file). Naming the action makes the message actionable.

Suggested change

	msgstr "qosify není spuštěné. Napravte to z karty Přehled."
	msgstr "qosify není spuštěné. Spusťte jej z karty Přehled."

---

Generated by Claude Code

[openwrt-ai]

Same superlative-vs-condition problem as the temperature/voltage entries flagged earlier in this file, now extended to the six power/bias labels added in this revision. Maximální přijímaný výkon means "maximum received power", but these keys are alarm/warning conditions, not measured maxima: they come from the L map in statusLabel() at sfp-info/main.js:173-184`` and are rendered as label notice / `label warning` badges meaning "RX power is high". The Spanish translation added in this same commit gets it right — `sfp-info/po/es/sfp-info.po:47` uses `Potencia RX alta`, not `máxima`.

Suggested change

	msgstr "Maximální přijímaný výkon"
	msgstr "Vysoký přijímaný výkon"

The same applies to five more entries here: line 51 → Nízký přijímaný výkon, line 87 → Vysoký TX výkon, line 91 → Nízký TX výkon, and lines 75/79, which additionally drop the polarizace qualifier that Bias Current gets on line 19 — TX bias high is a bias-current alarm, so Vysoký proud polarizace TX / Nízký proud polarizace TX rather than TX maximální proud.

---

Generated by Claude Code

[openwrt-ai]

nit: Sesgo is the statistical sense of "bias"; here TX bias is the transmitter's bias current, which this same file already translates correctly as Corriente de polarización on line 19. Both labels describe the same quantity — line 19 is the measured value column, lines 75/79 are its high/low alarm badges from statusLabel() at sfp-info/main.js:178-179`` — so they should use the same term.

Suggested change

	msgstr "Sesgo TX alto"
	msgstr "Corriente de polarización TX alta"

Line 79 below needs the matching change to Corriente de polarización TX baja.

---

Generated by Claude Code

[openwrt-ai]

This revision adds six more 100%-untranslated stub files, on top of the six already noted on the previous head. Every msgstr in each is empty and Last-Translator is still Automatically generated:

• applications/luci-app-qosify/po/pt_BR/qosify.po (this file, 167 strings, 721 lines)
• applications/luci-app-qosify/po/zh_Hans/qosify.po (167 strings, 721 lines)
• applications/luci-app-sfp-info/po/sv/sfp-info.po (30 strings)
• applications/luci-app-csshnpd/po/sv/csshnpd.po (32 strings)
• applications/luci-app-softether/po/sv/softether.po (5 strings)
• applications/luci-app-babeld/po/sv/babeld.po (3 strings)

The build-system side effect is the same as before: LUCI_LANGUAGES is derived from $(wildcard ${CURDIR}/po/*) at luci.mk:10, so each new po/<lang>/ directory generates a luci-i18n-<pkg>-<lang> package whose install rule at luci.mk:345-352 registers luci.languages.<lang> while shipping an empty .lmo. That is now ~1500 lines of empty stubs in this batch producing no translated string, four of them advertising Swedish for packages that have none.

Same question as before: can Weblate hold new components back until they carry at least one translated string, rather than committing the freshly generated skeleton?

---

Generated by Claude Code

[openwrt-ai]

Re-review after another force-push: the previously reviewed commit 997c14a8 was replaced by 18e7a7f3, so this covers git diff 997c14a8..18e7a7f3 — 54 .po files. The bulk is newly filled-in Lao (lo) and Simplified Chinese (zh_Hans) for qosify, sfp-info and strongswan-swanctl, a terminology sweep across the existing zh_Hans and lo catalogues, and two Polish files (aria2, nlbwmon).

Re-ran the mechanical checks over every entry whose msgstr changed in this range: no printf or %{...} placeholder drift, no HTML tag mismatches, no msgstr[n] count vs. header nplurals mismatches, no stray fuzzy flags. The %s-carrying strings newly translated in qosify/po/lo and qosify/po/zh_Hans all preserve their placeholders, and the 110% of this value strings in strongswan-swanctl/po/lo correctly keep the literal percent.

The zh_Hans terminology sweep (概况→概览, 活跃→活动, 入口/出口→入站/出站) is applied consistently — all 14 Overview and all 5 Active entries across the tree now agree — and the Polish changes are clean.

What is left is semantic, concentrated in the new qosify catalogues: one clear typo and one reversed meaning in the Chinese, plus a terminology collision in the Lao where three distinct service states share a single word. Inline below.

Earlier notes from the previous two rounds (Czech qosify/sfp-info strings, luci-app-https-dns-proxy being maintained out of tree, the empty stub language directories) are untouched by this push and still apply.

---

Generated by Claude Code

[openwrt-ai]

哟小 is not a word — this looks like a mistyped 有效. The string is the error shown when saveConfig() finds no parseable stanza,`` so it needs to read "no valid config stanzas found". Note the sibling string No valid UCI config stanzas in the same file is already rendered `无有效的 UCI 配置段`.

Suggested change

	msgstr "错误：未找到哟小的配置段。"
	msgstr "错误：未找到有效的配置段。"

---

Generated by Claude Code

[openwrt-ai]

"Prefix with + to override only when the DSCP field is zero" is rendered as 使其失效 ("make it ineffective"), which inverts the meaning: the + prefix still applies the DSCP value, it just restricts the override to packets whose DSCP field is already zero. This is the help text users read to decide whether to type + in a rule, so the reversed sense is actively misleading.

Suggested change

	"一个类。仅在 DSCP 字段为 0 时在前面加 + 符号使其失效。"
	"一个类。加 + 前缀表示仅当 DSCP 字段为 0 时才覆盖。"

The same mistranslation appears in the second copy of this sentence at line 399 (来让值失效) — worth fixing there too.

---

Generated by Claude Code

[openwrt-ai]

The sentence break is mangled: netdev. nat （此处默认值 0，接口默认值为 1）。 leaves nat dangling after an ASCII full stop with no predicate, so it reads as if nat were part of the netdev name rather than the option whose default differs. nat is the UCI option defaulted per section type in main.js:609,`` so it should be the subject of its own clause.

Suggested change

	msgstr "和接口选项相同，但名称是一个 netdev. nat （此处默认值 0，接口默认值为 1）。"
	msgstr "和接口的选项相同，但名称是一个 netdev。此处 nat 默认为 0，接口则默认为 1。"

---

Generated by Claude Code

[openwrt-ai]

nit: half-width , between CJK clauses, while the rest of this file consistently uses full-width ，/：/（） (e.g. 配置：%s, 已启用 — 未在整形流量（检查配置）).

Suggested change

	msgstr "%s 已上传, qosify 已重载。"
	msgstr "%s 已上传，qosify 已重载。"

Same mix at lines 24 (%s, 已应用 (已禁用 QoS)。 — also half-width parentheses) and 28 (%s, 已应用。).

---

Generated by Claude Code

[openwrt-ai]

Three distinct source strings collapse onto ກຳລັງເຮັດວຽກ in this file: Active (here), Running (line 492) and Working (line 627). qosify keeps these separate on purpose — updateEnBadge() renders Active from ctx.active (QoS actually shaping), while [`renderSvcTable()` uses `Running` as the row label for `ctx.running`](https://github.com/openwrt/luci/blob/18e7a7f3841bc6eec1c772cbc32965edb290cf59/applications/luci-app-qosify/htdocs/luci-static/resources/view/qosify/main.js#L470)`` (daemon process alive), and Working is only the busy-modal title next to Sending %s to qosify.... With one Lao word for all three, the status page shows the same label for "shaping" and "process is up", which is exactly the distinction the badge exists to convey — and Running — Not Shaping (line 488) then reads as a contradiction. Was the collapse intentional, or should Active get a shaping-specific term?

Same pattern in Config saved (line 133) and Settings saved (line 571), which both become ບັນທຶກການຕັ້ງຄ່າແລ້ວ even though they are two different notifications (config editor vs. Quick Settings form).

---

Generated by Claude Code

[openwrt-ai]

nit: not introduced by this push, but five lines above this hunk — base.po:3989, msgctxt "nft rt mtu" / Effective route MTU — the translation MTU ຂອງเส้นทางທີ່ມີຜົນ has the Thai word เส้นทาง spliced into the middle of a Lao string. The Lao equivalent used elsewhere in this file is ເສັ້ນທາງ. Since the Lao locale is being actively revised in this batch, it would be a good one to pick up in the same pass.

---

Generated by Claude Code