APB-I18N-EN-FAQ body.
Nested items have their own translatable fields
APB-I18N-EN-FAQ. Accordion items, tabs, and the read-more fold are nested paragraph entities. Under the symmetric model they keep the same IDs in every language. Each item title and body is a translatable field.
Questions that come up on a real desk
No. The host field is not translatable, so the parent list is shared. Add the band on English (the source) and then translate its copy. APB-I18N-EN-FAQ-ACC.
No. Color styles are taxonomy terms read by machine name. Translate the term label in the admin UI if you want the backend in Spanish; the front end does not use the label.
Those strings are fields on the item (`field_apb_pi_more_link`, `field_apb_pi_less_link`). They are translatable. The English source uses More / Less; Spanish should use Más / Menos.
The listing View is set to the current content language. On /es/internacional it should print the Spanish node title for each promoted page.
Three layers Drupal actually uses
Content Translation. One node, one ID, field values per language. This is what International Pages uses. APB-I18N-EN-FAQ-TAB.
locale / t(). Admin chrome, button labels in PHP and Twig. Interface language on this demo follows the user account, not the URL, so recordings stay in English.
config_translation. Field labels, paragraph type names, View titles. YAML defaults stay English. Enable the module and translate labels in the config UI if a desk needs Spanish admin.
A longer note that still has to fold
APB-I18N-EN-FAQ-RM. Aero Page Builder decided on the symmetric Paragraphs model: the same parents and items in every language. If the host field were translatable, each language would fork its own paragraph set. Preprocess, placement, and component JavaScript assume one tree. Asymmetric widgets exist in contrib; they are not the APB contract.
The practical cost is that a market which needs a unique band must either accept that band in every language or maintain a separate node. That is a product decision, not a Drupal bug.