Part 1 — Updating Confluence Pages (EN & ES)

1.1 — Page Structure Rules

• Maintain EN and ES content as separate Confluence pages. Never combine both languages into a single page with toggled or tabbed content.
• The ES page lives in the same parent space as its EN counterpart, named with the [ES] suffix (for example, GM Setup Guide [ES]).
• Both pages must share the same Jira reference number and release tag in their page metadata before either is submitted for review.
• Do not clone the EN page and edit for ES content. Author the ES page from scratch, using the ES Confluence template in the Template Library.
• Add page watchers to both the EN and ES pages before publishing. Watchers must include the assigned peer reviewer and the content lead.

1.2 — Authoring Sequence

1. Pull the Jira ticket and confirm scope: identify which Confluence pages require updates and which are new pages.
2. Draft the EN page first using the Confluence Template Library. Complete EN peer review and receive written approval before beginning the ES page.
3. Author the ES page independently. Do not copy or adapt from the EN draft. Consult Part 4 of this guide for approved terms and register rules.
4. Run both pages through the L10N Handoff Checklist before submitting to peer review.
5. Submit both pages to the Kanban board as a linked pair (see Part 2). The board will not accept a single-language submission.
6. After Content Lead approval, publish EN and ES simultaneously. Update the release notes index page with links to both.

1.3 — Common Mistakes to Avoid

Part 2 — Inline Manual Deliverables (EN & ES)

Inline Manual supports three types of in-app guidance within the NextGen Pulse POS interface. Each type has a specific authoring context and character scope. Writers must understand the appropriate application of each before beginning a deliverable.

• Walkthroughs: Step-by-step guided flows triggered on first login or at feature launch. Use walkthroughs for multi-step processes (for example, end-of-day close, inventory count).
• Tooltips: Single-step contextual hints attached to a specific UI element, triggered on hover or tap. Maximum 2 sentences per tooltip.
• Hotspots: Pulsing visual indicators that draw attention to a new or changed UI element. Hotspots contain label text only — no instructional copy.

2.1 — Authoring Rules by Type

Walkthroughs

• Author EN and ES as separate walkthrough flows in Inline Manual. Never use a single flow with conditional language logic.
• Each walkthrough has a maximum of 8 steps. Flows that exceed 8 steps must be split into linked flows with clear entry and exit points.
• Each step contains one action and one sentence. Do not combine two instructions in a single step.
• Button labels must reproduce the exact text that appears in the POS interface. Do not paraphrase or reword on-screen button labels.
• Author the ES walkthrough only after the EN walkthrough has completed peer review and received written approval. Do not author EN and ES in parallel.

Tooltips

• Maximum 2 sentences per tooltip. Sentence 1 describes what the UI element does. Sentence 2 (optional) states what the operator should do next.
• Avoid jargon. Do not use abbreviations unless they are listed and defined in the Style Guide (Part 4).
• Use only approved ES terms from the Glossary (Section 4.3). Do not improvise an ES equivalent for an unlisted term. Open a Jira ticket to request a Glossary addition.
• Character limit: 160 characters per tooltip, applied independently to EN and ES. Run a character count before submitting.

Hotspots

• Label text only: maximum 4 words in EN and 5 words in ES. (Spanish typically requires more characters to convey the same meaning.)
• Do not use a hotspot to explain a feature. If the element requires explanation, pair the hotspot with a tooltip.
• Submit hotspot labels to the Content Lead for approval before implementation. Do not implement unapproved hotspot labels.

2.2 — QA Environment Access

Test all Inline Manual content in the Jenkins QA environment before submitting for peer review. Access the QA environment at qa.inlinemanual.dominos-pulse.internal. For access issues, contact the Inline Manual Workspace lead listed on the QA Environment Access page.

Attach a screenshot of each walkthrough step, tooltip, and hotspot as rendered in the QA environment directly to the corresponding Jira ticket. QA screenshots are required before the Kanban card can move from Authoring to Peer Review.

2.3 — Submission Checklist

Part 3 — Kanban Review, Approval & Publish Workflow

All Confluence and Inline Manual deliverables pass through the team Kanban board before publishing. EN and ES deliverables are submitted as a linked pair. The board does not permit approving or advancing one language without the other. Writers create a single Kanban card that references both the EN and ES Jira tickets.

3.1 — Column Definitions

3.2 — Peer Review Rules

1. The peer reviewer cannot be the author of either the EN or ES deliverable under review.
2. The reviewer checks EN and ES against each other — not for literal equivalence, but for structural and tonal parity. Both languages should achieve the same instructional goal with the same level of clarity and confidence.
3. Log all review comments in the Jira ticket, not in Confluence page comments or Inline Manual annotations.
4. A deliverable returned from Peer Review must re-enter the queue from the Authoring column after the writer has addressed all comments. It cannot be fast-tracked to SME Review.
5. No deliverable advances to Approved without explicit Content Lead sign-off recorded in the Jira ticket. Verbal approvals are not accepted.

3.3 — Publish Coordination

Publish on the date confirmed in the Release Calendar. After publishing: update the release notes index page with links to both the EN and ES deliverables, close the Jira ticket, and archive any deprecated predecessor pages using the archive tagging convention in the Confluence Template Library.

Part 4 — EN/ES Style Guide & Approved Term Reference

The rules in this section are non-negotiable. Deviating from approved terms introduces inconsistency across the franchise network and erodes operator trust in the documentation system. If a term you need is not listed in Section 4.3, do not improvise an equivalent. Open a Jira ticket to request a Glossary addition (see Section 4.4 for terms currently under review).

4.1 — General Writing Rules (Both Languages)

• Use second-person active voice: "Tap Save" — not "The operator should tap Save."
• One instruction per sentence. Do not chain two actions with "and" or "then."
• Never use "click." Use "tap" — NextGen Pulse POS is a touchscreen system.
• Avoid idioms in both EN and ES. Write for literal comprehension across regional variants.
• Spell out numbers one through nine; use numerals for 10 and above.
• Do not abbreviate POS system feature names unless the abbreviation appears on-screen exactly as written.
• When referencing UI elements — button labels, screen titles, field names — match capitalization exactly as it appears in the interface.

4.2 — ES Register Rules (Spanish-Specific)

• Use Latin American Spanish register — neutral, not regional. Avoid vocabulary specific to Spain (for example, use computadora, not ordenador).
• Use usted (formal) for all operator-facing content. Do not use tú.
• Do not calque English idioms or sentence structures. Rewrite the concept in natural Spanish rather than preserving English syntax.
• POS-specific UI labels — button names, screen titles, field names — are not localized. They appear in English in the interface and must appear in English in the content, exactly as displayed.
• When a sentence reads awkwardly due to English sentence structure, restructure it in Spanish. Clarity in the target language takes precedence over proximity to the EN source.
• Accents and special characters (é, ñ, ¿, ¡) are required in all ES content. Never omit them for speed or compatibility.

4.3 — Approved Term Glossary

4.4 — Terms Under Review

The following terms are pending Glossary approval. Do not use these terms in any published content until an approved ES equivalent has been confirmed and added to Section 4.3.

Content Index

Parte 1 — Actualización de páginas en Confluence (EN y ES)

1.1 — Reglas de estructura de página

• Mantenga el contenido EN y ES como páginas separadas en Confluence. Nunca combine ambos idiomas en una sola página con contenido alternado o en pestañas.
• La página ES reside en el mismo espacio principal que su equivalente EN, con el sufijo [ES] en el nombre (por ejemplo, Guía de Configuración del GM [ES]).
• Ambas páginas deben compartir el mismo número de ticket de Jira y la misma etiqueta de versión en los metadatos de la página antes de enviarlas a revisión.
• No clone la página EN para editar el contenido ES. Redacte la página ES desde cero utilizando la plantilla ES de Confluence en la Biblioteca de Plantillas.
• Añada observadores a las páginas EN y ES antes de publicar. Los observadores deben incluir al revisor de pares asignado y al responsable de contenido.

1.2 — Secuencia de autoría

1. Descargue el ticket de Jira y confirme el alcance: identifique qué páginas de Confluence requieren actualizaciones y cuáles son páginas nuevas.
2. Redacte primero la página EN utilizando la Biblioteca de Plantillas de Confluence. Complete la revisión de pares EN y reciba la aprobación por escrito antes de comenzar la página ES.
3. Redacte la página ES de forma independiente. No copie ni adapte el borrador EN. Consulte la Parte 4 de esta guía para conocer los términos aprobados y las reglas de registro.
4. Ejecute ambas páginas a través de la Lista de Verificación de Entrega L10N antes de enviarlas a revisión de pares.
5. Envíe ambas páginas al tablero Kanban como un par vinculado (véase la Parte 2). El tablero no acepta envíos en un solo idioma.
6. Una vez recibida la aprobación del responsable de contenido, publique EN y ES simultáneamente. Actualice la página del índice de notas de versión con los enlaces a ambas páginas.

1.3 — Errores frecuentes que debe evitar

Parte 2 — Entregables de Inline Manual (EN y ES)

Inline Manual admite tres tipos de orientación en pantalla dentro de la interfaz de NextGen Pulse POS. Cada tipo tiene un contexto de autoría específico y un alcance de caracteres definido. Los escritores deben comprender la aplicación adecuada de cada tipo antes de comenzar un entregable.

• Guías paso a paso: Flujos guiados que se activan en el primer inicio de sesión o al lanzar una función. Úselas para procesos de varios pasos (por ejemplo, cierre del día, conteo de inventario).
• Notas de ayuda: Indicaciones contextuales de un solo paso, vinculadas a un elemento específico de la interfaz y activadas al tocar o al mantener el toque. Máximo 2 oraciones por nota.
• Indicadores visuales: Marcadores animados que llaman la atención sobre un elemento nuevo o modificado en la interfaz. Solo contienen texto de etiqueta —sin instrucciones.

2.1 — Reglas de autoría por tipo

Guías paso a paso

• Redacte EN y ES como flujos de guía separados en Inline Manual. Nunca utilice un único flujo con lógica de idioma condicional.
• Cada guía tiene un máximo de 8 pasos. Los flujos que superen los 8 pasos deben dividirse en flujos vinculados con puntos de entrada y salida bien definidos.
• Cada paso contiene una sola acción y una sola oración. No combine dos instrucciones en un mismo paso.
• Las etiquetas de los botones deben reproducir exactamente el texto que aparece en la interfaz POS. No parafrasee ni reformule las etiquetas de botones en pantalla.
• Redacte la guía ES solo después de que la guía EN haya completado la revisión de pares y recibido aprobación por escrito. No redacte EN y ES en paralelo.

Notas de ayuda

• Máximo 2 oraciones por nota de ayuda. La primera oración describe qué hace el elemento de la interfaz. La segunda oración (opcional) indica qué debe hacer el operador a continuación.
• Evite el lenguaje técnico. No utilice abreviaturas que no estén listadas y definidas en la Guía de Estilo (Parte 4).
• Utilice únicamente los términos ES aprobados del Glosario (Sección 4.3). No improvise un equivalente ES para un término no listado. Abra un ticket de Jira para solicitar la adición al Glosario.
• Límite de caracteres: 160 caracteres por nota de ayuda, aplicado de forma independiente al EN y al ES. Realice un recuento de caracteres antes de enviar.

Indicadores visuales

• Solo texto de etiqueta: máximo 4 palabras en EN y 5 palabras en ES. (El español generalmente requiere más caracteres para transmitir el mismo significado.)
• No utilice un indicador visual para explicar una función. Si el elemento requiere explicación, combine el indicador con una nota de ayuda.
• Envíe las etiquetas de los indicadores visuales al responsable de contenido para su aprobación antes de implementarlas. No implemente etiquetas sin aprobación.

2.2 — Acceso al entorno de QA

Pruebe todo el contenido de Inline Manual en el entorno de QA de Jenkins antes de enviarlo a revisión de pares. Acceda al entorno de QA en qa.inlinemanual.dominos-pulse.internal. Si tiene problemas de acceso, comuníquese con el responsable del Espacio de Trabajo de Inline Manual indicado en la página de Acceso al Entorno de QA.

Adjunte una captura de pantalla de cada paso de la guía, nota de ayuda e indicador visual tal como se renderizan en el entorno de QA, directamente en el ticket de Jira correspondiente. Las capturas de pantalla de QA son necesarias antes de que la tarjeta Kanban pueda avanzar de Autoría a Revisión de Pares.

2.3 — Lista de verificación de envío

Parte 3 — Flujo de Revisión Kanban, Aprobación y Publicación

Todos los entregables de Confluence e Inline Manual pasan por el tablero Kanban del equipo antes de publicarse. Los entregables EN y ES se envían como un par vinculado. El tablero no permite aprobar ni avanzar un idioma sin el otro. Los escritores crean una única tarjeta Kanban que hace referencia a los tickets de Jira EN y ES.

3.1 — Definiciones de columnas

3.2 — Reglas de revisión de pares

1. El revisor de pares no puede ser el autor de ninguno de los dos entregables —EN ni ES— que están bajo revisión.
2. El revisor verifica EN y ES de forma conjunta — no para comprobar equivalencia literal, sino para evaluar paridad estructural y de tono. Ambos idiomas deben alcanzar el mismo objetivo instruccional con el mismo nivel de claridad y confianza.
3. Registre todos los comentarios de revisión en el ticket de Jira, no en los comentarios de la página de Confluence ni en las anotaciones de Inline Manual.
4. Un entregable devuelto desde Revisión de Pares debe reingresar a la fila desde la columna de Autoría después de que el escritor haya atendido todos los comentarios. No puede avanzarse directamente a Revisión de Experto.
5. Ningún entregable avanza a Aprobado sin la firma explícita del responsable de contenido registrada en el ticket de Jira. Las aprobaciones verbales no son válidas.

3.3 — Coordinación de la publicación

Publique en la fecha confirmada en el Calendario de Versiones. Después de publicar: actualice la página del índice de notas de versión con los enlaces a los entregables EN y ES, cierre el ticket de Jira y archive las páginas predecesoras obsoletas utilizando la convención de etiquetado de archivo de la Biblioteca de Plantillas de Confluence.

Parte 4 — Guía de Estilo EN/ES y Referencia de Términos Aprobados

Las reglas de esta sección son de cumplimiento obligatorio. Desviarse de los términos aprobados introduce inconsistencia en toda la red de franquicias y erosiona la confianza de los operadores en el sistema de documentación. Si el término que necesita no figura en la Sección 4.3, no improvise un equivalente. Abra un ticket de Jira para solicitar una adición al Glosario (consulte la Sección 4.4 para los términos que están actualmente en revisión).

4.1 — Reglas generales de escritura (ambos idiomas)

• Use voz activa en segunda persona: "Toque Guardar" — no "El operador debe tocar Guardar."
• Una instrucción por oración. No encadene dos acciones con "y" o "luego."
• Nunca utilice "haga clic." Use "toque" — NextGen Pulse POS es un sistema de pantalla táctil.
• Evite los modismos en EN y en ES. Escriba de forma literal y comprensible para distintas variantes regionales.
• Escriba con letras los números del uno al nueve; use cifras para el 10 en adelante.
• No abrevie los nombres de funciones del sistema POS a menos que la abreviatura aparezca exactamente en pantalla.
• Al hacer referencia a elementos de la interfaz —etiquetas de botones, títulos de pantallas, nombres de campos— reproduzca exactamente la capitalización que aparece en la interfaz.

4.2 — Reglas de registro en ES (específicas para español)

• Utilice el registro de español latinoamericano — neutro, no regional. Evite el vocabulario específico de España (por ejemplo, use computadora, no ordenador).
• Use usted (formal) en todo el contenido dirigido a los operadores. No use tú.
• No calque modismos ni estructuras sintácticas del inglés. Reformule el concepto en español natural en lugar de preservar la sintaxis del inglés.
• Las etiquetas de interfaz del POS —nombres de botones, títulos de pantallas, nombres de campos— no se localizan. Aparecen en inglés en la interfaz y deben aparecer en inglés en el contenido, exactamente como se muestran.
• Cuando una oración resulte poco natural en español debido a la estructura del inglés, reestructúrela. La claridad en el idioma de destino tiene prioridad sobre la proximidad al texto EN fuente.
• Los acentos y caracteres especiales (é, ñ, ¿, ¡) son obligatorios en todo el contenido ES. Nunca los omita por comodidad o compatibilidad.

4.3 — Glosario de términos aprobados

4.4 — Términos en revisión

Los siguientes términos están pendientes de aprobación en el Glosario. No utilice estos términos en ningún contenido publicado hasta que se haya confirmado un equivalente ES aprobado y se haya añadido a la Sección 4.3.

Índice de contenido