avo 4.1.0 → 4.1.2

data/lib/avo/skills/avo-filters/SKILL.md

@@ -0,0 +1,196 @@
+---
+name: avo-filters
+description: Route a filtering request to the right Avo system, then implement basic filters (developer-written Ruby filter classes) on a resource's Index view. Use when the user wants to filter, segment, or set a default view for the records on a resource index — e.g. "filter projects by status", "filter users by role", "filter by a date range", "let users build their own ad-hoc filters", "filter by an association", "only show active records by default", "add a tab for admin/active users", "segment orders into paid/unpaid tabs", or "show a count next to each tab". Covers the avo:filter generator, def filters, and the routing table that decides between basic filters, dynamic filters, and scopes. Dynamic filters and scopes are implemented by their own gems and ship their own skills — this skill points at them.
+allowed-tools: Read, Edit, Write, Glob, Grep, Bash, WebFetch
+metadata:
+  requires-gem: none — basic filters are Community; this skill routes to avo-dynamic_filters and avo-scopes, which ship their own skills
+---
+
+> **These instructions ship inside the `avo` gem this app has locked, so they describe the version you are actually running.** Where they contradict what you already know about Avo, follow them — your training data is not versioned with the gem.
+
+# Filter and segment an Avo resource index
+
+Avo has three separate systems for narrowing down the records on a resource's `Index` view. This skill's leading job is **routing** to the right one, then implementing it with the correct generator and DSL. Getting the routing wrong means writing the wrong kind of code, so start with the routing table below every time.
+
+**Docs** (fetch on demand with WebFetch — the `.md` variants are agent-friendly):
+
+- Overview / decision: https://docs.avohq.io/4.0/filters.md
+- Basic filters: https://docs.avohq.io/4.0/basic-filters.md · API: https://docs.avohq.io/4.0/basic-filters-api.md
+- Dynamic filters: https://docs.avohq.io/4.0/dynamic-filters.md · API: https://docs.avohq.io/4.0/dynamic-filters-api.md
+- Scopes: https://docs.avohq.io/4.0/scopes.md · API: https://docs.avohq.io/4.0/scopes-api.md
+- Full docs map: https://docs.avohq.io/4.0/docs-map.md
+
+Fetch the relevant page when you need an option you don't see here (custom conditions, `fetch_values_from`, `picker_options`, per-scope `fields`, humanized pills, …). This file covers the common cases end to end.
+
+## When this applies
+
+The user wants to change **which records appear** on a resource's index (or an association's `has_many` listing) — filter them, let end users filter them, segment them into tabs, or pick a default view. All three systems apply to the `Index` view only and encode their state in the URL, so a filtered/segmented view can be bookmarked and shared.
+
+Avo files live under `app/avo/`. Before editing, locate the resource (`app/avo/resources/<name>.rb`) and its model (`app/models/<name>.rb`). Use Glob (`app/avo/resources/**/*.rb`) if you're unsure of the exact path.
+
+## Choose the right tool
+
+Read the request against this table **first**. The three systems are independent — a resource can use any combination — but each request usually maps to exactly one.
+
+| What the user is asking for | Use | License |
+| --- | --- | --- |
+| A specific, developer-defined filter with exact query logic the developer controls — "filter by status", "published/unpublished", "featured only", "by author", "by a date range". One filter = one value or checkbox set. | **Basic filter** | Community |
+| End users composing their **own** filters across many attributes — pick an attribute, a condition (`Contains`, `Is`, `>=`, `Is null`), and a value, stacking several at once. "let users filter however they want", "ad-hoc filtering", "filter by an association". | **Dynamic filters** | Paid add-on |
+| One-click **segment tabs** above the table — "add a tab for admins", "segment orders into paid/unpaid tabs", "Active / Archived tabs", "show a count next to each tab". | **Scopes** | Paid add-on |
+| A **default view** — "only show active records by default", "hide soft-deleted by default", "default to my team's records". | **Scope** marked `default: true` (optionally with `remove_scope_all`) | Paid add-on |
+
+Quick disambiguation:
+
+- **"Filter" is ambiguous.** If the developer decides the exact query and offers a fixed set of choices → basic filter. If the *end user* builds the query from a palette of attributes/conditions → dynamic filters.
+- **Tabs vs. filters.** A tab bar the user clicks between (mutually-exclusive segments, one active at a time) → scopes. A panel where the user sets values and applies → basic or dynamic filters.
+- **"By default" / "only show X" is almost always a default scope**, not a filter — filters start empty; scopes can be pre-applied.
+
+If the user's own words don't settle it, ask one clarifying question rather than guessing (e.g. "Do you want a fixed 'Status' filter you control, or should users build their own filters?").
+
+**License gate:** basic filters ship in Avo's **Community** edition. **Dynamic filters and scopes are paid add-ons** (`avo-dynamic_filters` and `avo-scopes` gems). If the routing lands on dynamic filters or scopes, mention the add-on requirement in your report so the user isn't surprised when the DSL is present but nothing renders on an unlicensed install.
+
+---
+
+## Basic filters
+
+One Ruby class per filter under `app/avo/filters/`. You choose the input type, define its `options`, and write the exact Active Record query in `apply`. Then register it on each resource that should show it.
+
+### Generate
+
+```bash
+bin/rails generate avo:filter published --type select
+```
+
+`--type` accepts `boolean` (default), `select`, `multiple_select`, `text`, and `date_time`. Each maps to a base class and a value shape in `apply`:
+
+| Type | Base class | `apply` receives |
+| --- | --- | --- |
+| `boolean` | `Avo::Filters::BooleanFilter` | `Hash` of `"option_id" => true/false` |
+| `select` | `Avo::Filters::SelectFilter` | `String` (selected option id) |
+| `multiple_select` | `Avo::Filters::MultipleSelectFilter` | `Array` of `String`s |
+| `text` | `Avo::Filters::TextFilter` | `String` |
+| `date_time` | `Avo::Filters::DateTimeFilter` | `String` (or `"<start> to <end>"` in range mode) |
+
+### Write the filter
+
+A select filter — the everyday "filter by status" case:
+
+```ruby
+# app/avo/filters/published.rb
+class Avo::Filters::Published < Avo::Filters::SelectFilter
+  self.name = "Published status"
+
+  # value is a String, e.g. "published"
+  def apply(request, query, value)
+    case value
+    when "published" then query.where.not(published_at: nil)
+    when "unpublished" then query.where(published_at: nil)
+    else query
+    end
+  end
+
+  def options
+    {published: "Published", unpublished: "Unpublished"}
+  end
+end
+```
+
+A boolean filter receives a hash keyed by option id — **read the keys as strings** (see Gotchas):
+
+```ruby
+# app/avo/filters/featured.rb
+class Avo::Filters::Featured < Avo::Filters::BooleanFilter
+  self.name = "Featured"
+
+  # values = { "is_featured" => true, "is_unfeatured" => false }
+  def apply(request, query, values)
+    return query if values["is_featured"] && values["is_unfeatured"]
+
+    if values["is_featured"]
+      query.where(featured: true)
+    elsif values["is_unfeatured"]
+      query.where(featured: false)
+    else
+      query
+    end
+  end
+
+  def options
+    {is_featured: "Featured", is_unfeatured: "Unfeatured"}
+  end
+end
+```
+
+A date-time filter — for "filter by a date range". Default `self.mode` is `:range`:
+
+```ruby
+# app/avo/filters/created_at.rb
+class Avo::Filters::CreatedAt < Avo::Filters::DateTimeFilter
+  self.name = "Created at"
+  self.type = :date    # :date_time (default), :date, or :time
+  self.mode = :range   # :range (default) or :single
+
+  def apply(request, query, value)
+    from, to = value.split(" to ")           # range arrives as "2024-08-13 to 2024-08-16"
+    query.where(created_at: Date.parse(from)..Date.parse(to))
+  end
+end
+```
+
+Text filters need no `options` (`value` is the raw string). Multiple-select filters get an `Array` of strings and `options` like select.
+
+### Register on the resource
+
+Filters only render once registered inside the resource's `filters` method:
+
+```ruby
+# app/avo/resources/post.rb
+class Avo::Resources::Post < Avo::BaseResource
+  def filters
+    filter Avo::Filters::Published
+    filter Avo::Filters::Featured
+  end
+end
+```
+
+The same filter class can be registered on many resources. To vary behavior per resource, pass `arguments: {...}` — available in `apply`, `options`, and the `self.name`/`self.visible` blocks.
+
+### Common extras (in the guide)
+
+- **Default state:** define `default` returning the same shape `apply` expects (`:published`, `{is_featured: true}`, `["a", "b"]`).
+- **Dynamic options:** `options` is plain Ruby — query the DB or an API.
+- **Conditional visibility:** `self.visible = -> { current_user.admin? }`.
+- **Filters that depend on each other:** read `applied_filters` in `options`, or override `react` to change a filter's own value when another changes.
+- **Link to a pre-filtered view:** `Avo::Filters::BaseFilter.encode_filters({"Avo::Filters::Name" => "Apple"})` → pass as `encoded_filters:`.
+
+---
+## Dynamic filters and scopes ship in their own gems
+
+Both are paid add-ons, and their instructions ship inside the gem that implements them — so they describe the version this app has locked, not a guess.
+
+| Subject | Gem | Skill to read |
+| --- | --- | --- |
+| End users composing ad-hoc filters — `filterable` fields, `dynamic_filter`, Ransack, the filters bar | `avo-dynamic_filters` | `avo-dynamic-filters` |
+| Segment tabs, default views, per-tab counts and columns | `avo-scopes` | `avo-scopes` |
+
+Re-run the Avo skills loader and read the skill from the path it prints for that gem. If the loader says the gem is not in `Gemfile.lock`, the app does not have it — tell the user which add-on provides the feature instead of writing DSL that will not render.
+
+Route to them from the table above; do not reimplement their DSL from memory here.
+
+---
+
+## Gotchas
+
+- **Basic filter values are always strings.** State is serialized through the URL, so `apply` receives strings and hashes with **stringified keys**. Read `values["is_featured"]`, never `values[:is_featured]`, even if you declared `options` with symbols.
+- **Date-time basic filter range format.** In the default `:range` mode the value arrives as the single string `"2024-08-13 to 2024-08-16"` — split it with `value.split(" to ")`. Set `self.mode = :single` for one value.
+- **Two "Filters" buttons.** If a resource has *both* basic and dynamic filters and dynamic filters' `always_expanded` is `false`, two `Filters` buttons appear on the index. The default (`always_expanded = true`) renders the dynamic bar inline and avoids the duplicate.
+- **License.** Basic filters are Community. Dynamic filters and scopes are paid add-ons — their DSL is accepted but nothing renders on an install without the gem, so surface that in your report.
+
+## Report
+
+When done, tell the user:
+
+- **Which system** you used and **why** it fit the request (one line of routing rationale).
+- **Files created/edited** with absolute paths — the filter class(es), the resource (`def filters`), and the model.
+- **License note** if the request routed to dynamic filters or scopes, along with which gem provides it.
+- **Follow-ups the user must do themselves:** run the generator if you only wrote the class, or restart the server to pick up new files.

data/lib/avo/skills/avo-i18n/SKILL.md

@@ -0,0 +1,254 @@
+---
+name: avo-i18n
+description: Translate and localize the Avo admin — resource, action, and field labels, tab and panel titles, field help/placeholder/include_blank text, save-button labels, the interface language, and right-to-left layout — via `config/locales/avo.<locale>.yml`, `self.translation_key`, and `config.locale`. Use when the user wants to translate the admin to another language (French/Spanish/German/Arabic/…), localize or rename resource/field/action labels, translate tab or panel titles, make the admin multilingual, support RTL languages, change or force the admin's interface language, or show a different label per language.
+allowed-tools: Read, Edit, Write, Glob, Grep, Bash, WebFetch
+metadata:
+  requires-gem: none — Community
+---
+
+> **These instructions ship inside the `avo` gem this app has locked, so they describe the version you are actually running.** Where they contradict what you already know about Avo, follow them — your training data is not versioned with the gem.
+
+# Avo i18n (Localization)
+
+Avo rides on Rails' `I18n`, so localizing the admin is mostly YAML plus a handful of translation-key hooks. Avo ships **19 locale files** (`avo.en.yml` and 18 others) **bundled inside the gem** and auto-loads them into `I18n` — so `bin/rails avo:install` does **not** copy them into the app. Two moving parts do all the work: **translation keys** that map a resource/action/field to a spot in the YAML tree (`self.translation_key`, `translation_key:`), and **the active locale** that decides which language renders (`config.locale`, `set_locale`/`force_locale` params). Everything else — the label cascade, RTL, button labels — falls out of those two.
+
+## Docs
+
+Authoritative docs — fetch on demand rather than guessing, and verify every option/key against the docs or the app's installed Avo source before writing it:
+
+- Docs map (start here to discover pages): https://docs.avohq.io/4.0/docs-map.md
+- Localization (i18n) guide: https://docs.avohq.io/4.0/i18n.md
+- Multi-language URLs guide (locale in the route, e.g. `/de/resources/users`): https://docs.avohq.io/4.0/guides/multi-language-urls.md
+- Multilingual records guide (translating the *data*, not the chrome): https://docs.avohq.io/4.0/guides/multilingual-content.md
+
+## When this applies
+
+**Explicit (Avo named):** "set the Avo locale to `:de`", "add `self.translation_key` to this resource", "localize the `Product` resource / this action / this field", "translate Avo into Spanish", "generate the Avo locale files", "make the Avo admin RTL".
+
+**Implicit (no mention of Avo/i18n):** "translate the admin to French / Spanish / German", "the admin needs to be in Arabic" or "support right-to-left", "localize the resource / field / action labels", "rename this field's label per language", "make the admin multilingual", "change the admin's language", "different label depending on the language", "the field help text should be translated", "customize the Save button wording for this one resource".
+
+**Not this skill:** translating the *content of records* (a `title` column that differs per language) is the **multilingual records** guide, not i18n. Putting the locale in the URL (`/en/...`, `/de/...`) is the **multi-language URLs** guide. Point the user there and stop.
+
+## Workflow
+
+### 1. Get editable locale files
+
+Avo's locale files live inside the gem and are not copied on install. To edit any Avo-provided string (or add a brand-new language), generate local copies first:
+
+```bash
+bin/rails generate avo:locales
+```
+
+That copies all bundled `avo.<locale>.yml` files into `config/locales/`. Edit the ones you need; add `config/locales/avo.<new_locale>.yml` for a language Avo doesn't ship, using a shipped file as the template. Rails auto-loads everything under `config/locales`, so no registration step.
+
+For **custom** resource/action/field labels (the common case), you don't need the generator at all — just add your own keys under the `avo:` namespace in any locale file (e.g. `config/locales/avo.en.yml`), following the shapes below.
+
+### 2. Localize a resource
+
+Set `self.translation_key` on the resource, then supply the pluralized name under that key. This changes the resource's label **everywhere** in Avo (sidebar, breadcrumbs, headings):
+
+```ruby
+# app/avo/resources/user.rb
+class Avo::Resources::User < Avo::BaseResource
+  self.title = :name
+  self.translation_key = "avo.resource_translations.user"
+end
+```
+
+```yaml
+# config/locales/avo.es.yml
+es:
+  avo:
+    resource_translations:
+      user:
+        zero: "usuarios"
+        one: "usuario"
+        other: "usuarios"
+```
+
+Omit `self.translation_key` and Avo derives it from the class name, **namespace included** — `Avo::Resources::Galaxy::Planet` defaults to `avo.resource_translations.galaxy/planet`. So for a plain resource you often only need the YAML, no Ruby change.
+
+### 3. Localize an action
+
+Same convention. Avo looks under `avo.action_translations.<class_path>` for the `name`, `message`, `confirm_button_label`, `cancel_button_label`, and `description` sub-keys before falling back to the class attributes (`self.name`, `self.message`, …):
+
+```ruby
+# app/avo/actions/toggle_inactive.rb
+class Avo::Actions::ToggleInactive < Avo::BaseAction
+  # Optional — defaults to avo.action_translations.toggle_inactive
+  # self.translation_key = "avo.action_translations.toggle_inactive"
+end
+```
+
+```yaml
+# config/locales/avo.sv.yml
+sv:
+  avo:
+    action_translations:
+      toggle_inactive:
+        name: "Växla inaktiv"
+        message: "Är du säker på att du vill växla inaktiv status?"
+        confirm_button_label: "Växla"
+        cancel_button_label: "Avbryt"
+        description: "Växlar den inaktiva statusen för användaren"
+      city/update:            # namespaced: Avo::Actions::City::Update
+        name: "Uppdatera stad"
+```
+
+`self.name`/`self.message`/button labels (strings **or** lambdas) remain the fallback when no key is translated — keep them for dynamic labels that depend on `arguments`/`record`.
+
+### 4. Localize fields
+
+When a field has no explicit `translation_key:`, Avo resolves its label through a **cascade**, using the first key that has a translation:
+
+1. `avo.resource_translations.<resource>.fields.<field_id>` — resource-scoped; overrides a label for **one** resource.
+2. `avo.field_translations.<field_id>` — shared across every resource using that field id.
+3. Humanized field id — the fallback.
+
+Point a field at the shared key explicitly with `translation_key:` (this **bypasses the cascade** entirely):
+
+```ruby
+# app/avo/resources/project.rb
+class Avo::Resources::Project < Avo::BaseResource
+  def fields
+    field :id, as: :id
+    field :files, as: :files, translation_key: "avo.field_translations.file"
+  end
+end
+```
+
+```yaml
+# config/locales/avo.es.yml
+es:
+  avo:
+    field_translations:
+      file:
+        one: "archivo"
+        other: "archivos"
+    resource_translations:
+      product:
+        fields:
+          title:                # wins over field_translations.title, only on Product
+            one: "Título del producto"
+            other: "Títulos del producto"
+```
+
+**`help`, `placeholder`, and `include_blank`** resolve from **sibling keys under the same translation key** — no need to pass them in Ruby. Set them once in YAML and drop the Ruby options:
+
+```yaml
+# config/locales/avo.sv.yml
+sv:
+  avo:
+    field_translations:
+      dates:
+        one: "Datumintervall"
+        other: "Datumintervall"
+        help: "Valfritt. Standardperiod: 1 vecka tillbaka till idag."
+        placeholder: "Välj datum"
+        include_blank: "Ingen"
+```
+
+```ruby
+field :dates, as: :date_time   # help/placeholder/include_blank come from the locale
+```
+
+Explicit `help:`/`placeholder:`/`include_blank:` (strings or lambdas) still win over the locale file.
+
+### 5. Localize tabs and panels
+
+Tab and panel titles resolve through the **resource's** translation key too. Avo parameterizes the configured `title:` (downcased, non-alphanumerics turned into `_`) and looks it up under a `tabs` or `panels` scope:
+
+- `avo.resource_translations.<resource>.tabs.<title>` for a `tab`
+- `avo.resource_translations.<resource>.panels.<title>` for a `panel`
+
+So `tab title: "Activity"` resolves to `avo.resource_translations.user.tabs.activity`, and `panel title: "Contact information"` to `avo.resource_translations.user.panels.contact_information`:
+
+```yaml
+# config/locales/avo.es.yml
+es:
+  avo:
+    resource_translations:
+      user:
+        tabs:
+          activity: "Actividad"
+        panels:
+          contact_information: "Información de contacto"
+```
+
+The configured `title:` stays the fallback when the key has no translation. To pin a different key, pass `translation_key:` to the `tab` or `panel` and Avo uses it verbatim:
+
+```ruby
+tab title: "Activity", translation_key: "avo.resource_translations.user.tabs.recent_activity" do
+  # ...
+end
+```
+
+### 6. Localize button labels
+
+`avo.save` covers every Save button globally. To override it for **one** resource, add a `save` key under that resource's translation key:
+
+```yaml
+# config/locales/avo.en.yml
+en:
+  avo:
+    resource_translations:
+      product:
+        save: "Save the product!"
+```
+
+### 7. Set or switch the interface language
+
+`config.locale` sets Avo's locale for **Avo requests only** — the rest of the app keeps `config.i18n.default_locale`. Default is `nil` (falls back to the app default):
+
+```ruby
+# config/initializers/avo.rb
+Avo.configure do |config|
+  config.locale = :de   # default: nil
+end
+```
+
+Two request params switch language on the fly:
+
+- **`?set_locale=pt-BR`** — sets Avo's default locale process-wide **until the server restarts** (it mutates `Avo.configuration.locale`). Affects every user; use it as a switch, not per-user preference.
+- **`?force_locale=pt-BR`** — sets the locale for that request only, but Avo **keeps the param in every link** while you navigate. Remove it to return to the configured locale. Good for previewing a translation without changing config.
+
+### 8. Right-to-left languages
+
+RTL is **automatic** — Avo detects it from the active locale and flips the layout (`dir="rtl"`, mirrored chrome) with no configuration. Built-in RTL locales: `ar`, `he`, `fa`, `ur`, `yi`, `ps`, `sd`, `ku`, `ckb`, `ug`, `dv`. Matching is on the **language segment**, so regional variants like `ar-EG` count as RTL too. To ship an Arabic admin, translate into `avo.ar.yml` and set the locale — the layout follows.
+
+## Key options
+
+| Hook | Where | Does |
+| --- | --- | --- |
+| `self.translation_key` | Resource class | Maps the resource to `avo.resource_translations.<...>`; changes its label everywhere. Defaults from class name (namespace included). |
+| `self.translation_key` | Action class | Maps the action to `avo.action_translations.<...>` (`name`/`message`/`confirm_button_label`/`cancel_button_label`/`description` sub-keys). |
+| `translation_key:` | Field declaration | Pins the field to one key and **skips the cascade**. Omit to use resource-scoped → shared → humanized. |
+| `avo.resource_translations.<r>.fields.<f>` | YAML | Resource-scoped field label — overrides the shared one for a single resource. |
+| `avo.field_translations.<f>` | YAML | Shared field label + `help`/`placeholder`/`include_blank` siblings across all resources. |
+| `avo.resource_translations.<r>.tabs.<t>` | YAML | Tab title, keyed on the parameterized `title:`. Pin a different key with `translation_key:` on the `tab`. |
+| `avo.resource_translations.<r>.panels.<p>` | YAML | Panel title, same convention as tabs; `translation_key:` on the `panel` overrides it. |
+| `avo.resource_translations.<r>.save` | YAML | Per-resource Save-button text (else global `avo.save`). |
+| `config.locale` | Initializer | Avo's interface language for Avo requests only. Default `nil` → app default. |
+| `?set_locale=` param | URL | Switches Avo's default locale process-wide until restart. |
+| `?force_locale=` param | URL | Switches locale for the current navigation only; sticks in links until removed. |
+| `bin/rails g avo:locales` | Shell | Copies the 19 bundled locale files into `config/locales` for editing. |
+
+## Gotchas
+
+- **Locale files ship inside the gem — not copied on install.** To edit Avo's own strings or add a language, run `bin/rails g avo:locales` first. For custom labels you only need your own keys under `avo:`; the generator is optional.
+- **Explicit `translation_key:` on a field bypasses the cascade.** You lose the resource-scoped → shared → humanized fallback and the automatic `help`/`placeholder`/`include_blank` sibling lookup. Only pin a key when you want exactly that key.
+- **Default keys include the namespace.** `Avo::Resources::Galaxy::Planet` → `avo.resource_translations.galaxy/planet`; `Avo::Actions::City::Update` → `avo.action_translations.city/update` (underscored, slash-joined). Match that path in YAML or the lookup misses and you fall back to the humanized name.
+- **Pluralization keys are required.** Resource/field name lookups run `I18n.t(key, count:, default:)`, so provide `one`/`other` (and `zero` where relevant). A bare string can raise `I18n::InvalidPluralizationData` or silently fall back to the computed name.
+- **`set_locale` is global and sticky.** It mutates `Avo.configuration.locale` and persists until the server restarts, affecting all users — it is not a per-user preference. Use `force_locale` for a scoped, reversible switch (it rides along in every link until removed).
+- **RTL is automatic and matches on the language segment.** `ar`, `he`, `fa`, `ur`, `yi`, `ps`, `sd`, `ku`, `ckb`, `ug`, `dv` — and regional variants (`ar-EG`) — flip the layout with no config. Don't hand-roll a direction toggle.
+- **Don't confuse chrome with data.** This skill localizes labels/buttons/help (the admin UI). Translating record *content* is the multilingual-records guide; putting the locale in the URL is the multi-language-URLs guide.
+- **Verify before writing.** Key names and the cascade drift between versions — check the docs URL above or the app's installed Avo source rather than trusting memory.
+
+## Report
+
+When done, tell the user:
+
+- Which locale file(s) you created or edited (full paths) and any resource/action/field file(s) where you set `translation_key`, plus any generator command run (`bin/rails g avo:locales`).
+- The translation keys you added and the resource/action/field each targets — call out where you relied on the field cascade vs. an explicit `translation_key:`.
+- The active-locale change, if any (`config.locale`, or that they can preview with `?force_locale=`), and whether RTL will engage for the chosen language.
+- Anything still needed: add the remaining `one`/`other` plural forms, translate the other bundled strings, restart the server after a `config.locale` change, or move to the multilingual-records / multi-language-URLs guide if the real goal was record content or locale-in-URL.