Customize reader-facing text and appearance
Start with the reader surface you intend to change: an email, an authentication form, a popup page or the publication's website. These are different implementations; one template edit does not change all of them.
Identify the responsible owner
| Surface | Where the change belongs |
|---|---|
| Email subject and body | The publication's E-mail Templates and the workflow using them. |
| Authentication provider button or form title | The deployed website integration, where its version supports those options. |
| A technical popup template | The appropriate Popup Templates record and the consumer that selects its route/version. |
| Overall website theme and page layout | The publication's website implementation. |
Popup Templates edits HTML, CSS and JavaScript for a popup. Ask the integration owner about authentication labels in the interface your site uses. A popup document's Title is not automatically the heading inside a form.
Write a precise request
For City Journal, a brief for the integration owner could request:
| Item | Requested copy |
|---|---|
| Email-provider button in the sign-in state | Sign in to City Journal |
| General email-provider button label | Continue with email |
| Sign-in form heading, if supported | Welcome to City Journal |
These are requested labels, not configuration to paste into Admin. The integration owner must confirm the actual consumer and deployed version before applying them.
Include the publication, page or popup route, provider, sign-in/sign-up state, language, current copy and requested copy. For branding, specify the intended colors or existing approved asset and the surface it should affect. Keep secret links, tokens and reader data out of the brief.
Agree fallback and coverage
In the supported integration version, separate sign-in/sign-up provider labels can override a general label. A missing state-specific label can fall back to that general label. Form titles and submit/cancel labels have separate defaults.
That behavior belongs to the compatible integration version, rather than every Wallkit popup or SDK. Confirm which labels the deployed interface supports, what happens when a value is omitted, and which languages and states the change covers. Do not assume a sign-in change also changes sign-up or that all integrations use the same defaults.
The technical popup consumer selects a template and version through a different path. Its Active, publication and explicit-version selection rules are not interchangeable with email-template saving or integration label settings. Have the owner identify the exact template before changing it.
Make the handoff reviewable
Agree the intended surface, copy, branding and owner. After implementation, review the changed interface in the relevant state and language. Check what readers see rather than relying only on the saved setting.
For website setup context, use Prepare your website integration. For email copy, use Prepare a message template.