mirror of
https://github.com/vladmandic/automatic
synced 2026-09-04 20:10:45 +02:00
Vladimir Mandic
51 lines
3.0 KiB
Markdown
51 lines
3.0 KiB
Markdown
---
|
|
description: "Use when editing hint text or other UI strings in localization JSON files; follow the ordered rules below for consistent formatting."
|
|
name: "Hint Typography Guidelines"
|
|
applyTo: "ui/locale/*.json"
|
|
---
|
|
# Hint Typography Guidelines
|
|
|
|
Hint strings render as HTML. Use this small set of inline tags to keep hints scannable:
|
|
|
|
1. `<b>` for values: defaults, dropdown enums, specific numerics. Examples: `<b>0.30</b>`, `<b>Karras</b>`, `<b>v_prediction</b>`, `<b>UniPC</b>`.
|
|
2. `<b><i>...</i></b>` for cross-references to other UI controls by their exact visible label. Examples: `<b><i>Denoising strength</i></b>`, `<b><i>Use init image</i></b>`, `<b><i>Images</i></b>` tab.
|
|
3. `<i>` for proper nouns: model families, datasets, technique names. Examples: `<i>SDXL</i>`, `<i>Flux</i>`, `<i>ControlNet</i>`, `<i>YOLO</i>`.
|
|
4. `<code>` for literals: paths, filename tokens, command-line snippets to type or use verbatim. Examples: `<code>models/yolo</code>`, `<code>-seg</code>`, `<code>[PROMPT]</code>`.
|
|
|
|
## Cross-references
|
|
|
|
1. Use `<b><i>...</i></b>` whenever a hint refers to another control by its exact visible label. This includes setting names, tab names, and named buttons.
|
|
2. Match the label exactly, including capitalization and spacing; readers look for the same string in the UI.
|
|
3. Do not use `<b>` and `<i>` separately for cross-references; always combine them.
|
|
4. Generic concept references (`the model`, `the prompt`, `the scheduler`) stay unstyled.
|
|
|
|
## Tab naming
|
|
|
|
1. Refer to the unified generation tab as `<b><i>Images</i></b>` (the ModernUI label). Do not write "Control tab"; that label only exists in legacy Standard UI.
|
|
2. "Control" remains valid as a setting value (`<b>No: Control only</b>`) or as part of a UI element name (`<b><i>Control input</i></b>` pane), just not as a tab name.
|
|
|
|
## Structure
|
|
|
|
1. `<br>` for a line break within a paragraph.
|
|
2. `<br><br>` for a paragraph break.
|
|
3. `<br>- <b>key</b>: description` for a keyed bullet list, used for short enumerations of dropdown values, modes, or numeric brackets. Each bullet's key is bolded; descriptions stay plain.
|
|
4. Do not use `<ul>`, `<li>`, Markdown asterisks, or unicode bullets.
|
|
|
|
## Common pitfalls
|
|
|
|
1. Do not bold ad-hoc emphasis; `<b>` is reserved for values and, combined with `<i>`, for cross-references.
|
|
2. Do not use `<b>` for filenames, paths, or command tokens; those are literals and use `<code>`.
|
|
3. Do not reword the inside of `<code>` blocks; they are literal user-facing strings.
|
|
4. Stay ASCII; prefer semicolons or two sentences over em-dashes. The locale file convention is ASCII-only.
|
|
|
|
## Translation propagation
|
|
|
|
1. `ui/locale/locale_en.json` is the source of truth. Other `ui/locale/locale_*.json` files are auto-generated by `cli/localize.js`; edit only the English file.
|
|
2. Per-locale corrections live in `ui/locale/override_{locale}.json`.
|
|
|
|
## Validation
|
|
|
|
1. Validate JSON syntax with `jq empty ui/locale/locale_en.json`.
|
|
2. Lint with `pnpm eslint -- ui/locale/locale_en.json` (silent success).
|
|
3. See `wiki/Hints.md` for the wiki-facing version of these rules.
|