[Idea]: Investigate and standardize placeholder format for sensitive values in examples across NGINX documentation

[FaithKovi]

What is your idea for improving documentation?

While discussing Replace examples of sensitive values with explicit placeholders
#1363, it became clear that there may not be a documented or consistently applied placeholder format across the NGINX documentation sets.

The goal is to improve clarity for users, reduce confusion when copying examples, and avoid false positives from security scanning tools caused by plausible sensitive values.

Which product or products does this idea relate to?

Other

Does this idea relate to other issues?

Yes, it relates to #1363

Are there alternative ideas for improving the same topic?

No response

Any additional information

Description

The contributing guide instructs contributors to replace personal and sensitive information in documentation examples with generic placeholders. However, no specific placeholder format is defined, which leads to inconsistent usage across the documentation.

This issue proposes a short investigation to:

• Identify the placeholder patterns that are already in use in parts of the documentation
• Propose and define a single, clear placeholder convention in the style guide that can be reused across all documentation, with provided examples

Acceptance criteria

• A placeholder format is clearly documented and easy to follow
• Placeholder values are distinct and cannot be mistaken for real data
• The guidance supports both user clarity and security scanning tools

[FaithKovi]

Hello @mjang , I would like to work on this. Please assign.

[FaithKovi]

Hello @mjang, below is my investigation and proposed solution. Let me know what you think.

Investigation discovery

From my investigation, there are several placeholder formats used within the docs. Some include;

• <username>
• <tag-name>
• <seed value>
• <NIM_FQDN>

Proposed format
I would like to propose the following based on the Microsoft writing style guide (the guide recommended by the Nginx style guide for topics it does not cover)

• Using italics in text for placeholders in sentences and steps.

Example:
Replace your-domain with your actual domain.
Enter your API key when prompted.

• Using angle brackets (< >) in commands, configs, and code samples with descriptive text telling users to replace them.

Example 1:
curl -H "Authorization: Bearer <api-token>" https://<your-domain>/api
Replace the values in angle brackets with your own.