Repository navigation
Localization Quality and Turkish Terminology
HWcontrol2.0 uses BCP 47 locale identifiers and keeps the English (US) catalog as the source-key reference. Locale tags follow Unicode CLDR/LDML conventions. A locale is not considered fully translated merely because a language option appears in the selector: every source key must exist, text must be reviewed for meaning and context, and the UI must be checked for truncation and accessibility.
The Turkish interface should use clear, natural Türkiye Turkish and established Turkish computing terms where they fit. Prefer understandable Turkish equivalents over unnecessary English wording, but do not invent awkward replacements for recognized terms, hardware standards, file formats, product names, or protocol identifiers. Keep names such as HWcontrol2.0, Piper, and ONNX intact where they identify a product or technical format.
Initial terminology decisions:
- Dashboard → Ana ekran
- Telemetry history → Ölçüm geçmişi
- RAM usage → Bellek kullanımı
- GPU usage → Ekran kartı kullanımı
- Fan / fan speed → Soğutucu pervanesi / Soğutucu pervanesi hızı
- Game mode → Oyun kipi
- Control flow → Denetim akışı
- Advanced telemetry → Gelişmiş ölçümler
- Save profile → Ayar takımını kaydet
- Test speech / read dashboard → Sesli okumayı dene / Ana ekran özetini sesli oku
These are product terminology choices, not a claim that every word of foreign origin has been removed from Turkish. User comprehension and technical accuracy take precedence over forced word substitution. Review terminology consistently across visible UI, accessibility announcements, help text, and documentation.
The default is Standart Türkçe. Turkish users may optionally select Edebî Türkçe in the language settings for a more flowing, carefully composed interface voice. The literary style should improve rhythm and phrasing without becoming archaic, ornate, vague, or harder to understand. It is not a separate language or a translation of the whole application.
The canonical messages, technical terminology, placeholders, and locale fallback remain owned by the ARB catalogs. The optional file at gui_dashboard/assets/l10n/variants/tr_TR/literary.json is a narrowly scoped style overlay: it may override only existing Turkish message keys and otherwise falls back to the canonical ARB wording. It is not a second locale catalog and must not be used for English or other locales. The current overlay contains 66 curated entries; its count is separate from the 235 canonical source-message keys.
Security blocks, update-verification states, automation safety notes, hardware-control limitations, and critical installation errors are protected from stylistic overrides. Any future entry with placeholders must preserve the exact placeholder set. Tests check key existence, string values, placeholder parity, protected messages, standard-style fallback, and that the literary preference does not affect English. If an overlay is missing, malformed, or invalid, the application must start with canonical ARB text rather than fail.
Keep Standard Turkish as the default and use Edebî Türkçe only where the longer wording remains legible in the actual UI. Review the full visible sentence in context; do not mechanically make every label longer. Do not add an Ottoman-style variant.
The English (US) ARB template currently contains 235 message keys across 40 locale catalogs. Automated checks verify locale identifiers, required-key coverage, ICU placeholder parity, metadata consistency, the generated compatibility adapter, and the absence of runtime references to the removed JSON localization asset. Thirteen newer security/update status messages are currently supplied in English and Turkish; other locales use the English template fallback for those messages. The two parameterized accessibility/automation summaries are present in all 40 regional catalogs, with placeholder parity checks. The ICU plural messages for anomaly counts and benchmark iterations are present in all 40 catalogs. This is structural validation, not proof of native-quality translation: every locale still needs contextual linguistic review, regional terminology review, and UI layout/accessibility checks. Do not describe all 40 as professionally reviewed or fully quality-assured until those steps are completed.
- For Turkish (Türkiye), consult TDK's Güncel Türkçe Sözlük, Yazım Kılavuzu, and Yabancı Sözlere Karşılıklar Kılavuzu. Record why a term was selected when alternatives compete.
- For each other locale, prefer the relevant official language institution, national terminology database, statutory spelling council, or recognized academic normative dictionary. Confirm that the source applies to the actual regional locale (for example, es-MX vs es-ES and pt-PT vs pt-BR). Not every language has a single government-mandated authority; do not label a private dictionary as an official government source.
- Use Unicode CLDR/LDML and BCP 47 conventions for locale identifiers, regional variants, plural rules, number/date formats, and text direction.
- Translate in context, preserving placeholders, units, punctuation, product names, and technical identifiers. Hardware terms should be understandable to ordinary users but remain technically precise.
- Validate exact key parity, non-empty strings, placeholder parity, duplicate locale codes, RTL direction, fallback behavior, and suspicious untranslated English strings. An identical string is acceptable for a product name, standard, protocol, or common technical acronym; it should be reviewed rather than automatically rejected.
- Run localization unit tests, Flutter analysis/tests, and visual checks for truncation and accessibility for every completed locale.
- Add new locales only with a complete translation set; do not increase the advertised language count with English placeholders.
The expanded 40-locale source inventory, source-status rules, term research template, reuse-rights cautions, and review plan are maintained in Language Authority and Terminology Research Registry. Use that registry as a research queue; do not treat a listed link as verified for every term or as proof of official endorsement.
Use these as primary starting points, not as an automated substitute for a native-language review. Record the date and the term checked when adopting a terminology decision.
| Locale / language | Preferred reference | Scope |
|---|---|---|
| tr-TR — Turkish (Türkiye) | TDK Current Turkish Dictionary, TDK spelling guide, Foreign Words Equivalents Guide | Spelling, established words, Turkish equivalents |
| es-ES / es-MX — Spanish | RAE / ASALE Dictionary of Doubts | Shared Spanish guidance; check regional usage rather than assuming Spain-only wording |
| fr-FR — French | FranceTerme / French terminology resources, Académie française dictionary and terminology resources | French technical terminology and normative usage |
| de-DE — German | Council for German Orthography and its current official rules | Standard spelling and punctuation |
| ja-JP — Japanese | Agency for Cultural Affairs: Japanese language policy | Government language policy and writing references |
| ca-ES — Catalan | Institut d'Estudis Catalans — DIEC | Normative Catalan lexicon |
| pt-PT — Portuguese (Portugal) | Academia das Ciências de Lisboa — VOLP | Portuguese spelling and lexical forms for the Portugal variety |
| pt-BR — Portuguese (Brazil) | Check Brazilian official/academic lexicographic resources and the applicable orthographic agreement; do not copy Portugal-specific vocabulary blindly | Brazilian regional usage |
| bn-BD — Bengali (Bangladesh) | Bangla Academy | Bengali dictionaries and editorial references |
| zh-CN / zh-TW — Chinese | Consult the relevant mainland Chinese or Taiwan language-standardization/dictionary source separately; do not treat Simplified and Traditional Chinese as merely different fonts | Regional vocabulary, characters, and terminology |
| Other locales | Identify a recognized language authority or national/academic terminology source for the specific locale before final review | Authority varies by language and country |
The authority/source mapping is deliberately regional. For example, RAE/ASALE guidance supports shared Spanish norms but does not remove the need to review Mexican wording; likewise, the Portuguese authority listed for pt-PT must not be treated as the sole authority for pt-BR.
- TDK — Yabancı Sözlere Karşılıklar Kılavuzu
- TDK — Güncel Türkçe Sözlük
- TDK — Yazım Kılavuzu
- RAE / ASALE — Diccionario panhispánico de dudas
- Académie française — Terminologie
- German Orthography Council
- Japan Agency for Cultural Affairs — Japanese language policy
- Institut d'Estudis Catalans — DIEC
- Academia das Ciências de Lisboa — VOLP
- Bangla Academy
- Unicode CLDR/LDML specification
- Flutter internationalization guide
ARB is now the canonical source for user-visible UI messages. The former assets/localization/language.json runtime catalog has been removed; application and installer localization must not load, search for, or silently recreate it. Flutter's gen-l10n generates typed AppLocalizations accessors from lib/l10n/app_*.arb, and l10n.yaml defines the source template and generated class.
Use ICU message syntax when grammar depends on a value, especially plural counts and selection. Use declared typed placeholders for paths, errors, versions, platform names, percentages, and other interpolated values. Avoid manually replacing {placeholder} strings in application code when a generated accessor is available. The app_localizations_map.dart adapter is a compatibility boundary for older key-based widgets, not a second translation catalog: it reads only Flutter-generated ARB accessors. The dashboard now materializes only the selected locale's compatibility map instead of keeping all regional maps in memory. Base-language ARB files provide Flutter's required locale fallbacks; the language selector exposes only the 40 regional choices, and language-only OS locales resolve to a preferred regional catalog. Tests verify every key-based call is mapped and that parameterized messages use generated typed accessors. New or changed parameterized messages should use generated typed accessors.
The ARB migration does not mean every JSON or INI file should become ARB. Settings, fan curves, profiles, telemetry, model metadata, update manifests, and security manifests are structured data, not translated messages. Keep their existing schemas and compatibility/migration code unless a separate data-format migration is designed and validated. In particular, do not remove legacy configuration migration merely because it mentions INI.
- Keep all 40 regional locale catalogs and preserve BCP 47 identifiers.
- Validate ICU syntax by running
flutter gen-l10nin CI, then runflutter analyzeandflutter test. - Test key coverage, placeholder metadata and parity, ICU plural coverage, locale naming, adapter parity, RTL behavior, and the absence of references to the removed localization JSON asset.
- Treat English template fallback as a temporary translation gap, not as a completed translation. New security/update messages must be reviewed and translated for each locale before claiming full coverage.
- Do not maintain JSON and ARB as parallel localization sources of truth.
- Review locale changes visually for truncation, accessibility, and RTL layout before release.