hana-developer-cli-tool-example translatable-text-handling.instructions.md

A set of instructions for handling text shown to users in command-line tools, web routes, and shared utilities.

In plain words
What is it for?
It is for adding or changing help text, labels, errors, warnings, and other visible messages using the project's translation system.
Why use it?
It prevents user-facing messages from being hard-coded in one language and keeps translations organized across language files.

Instructions file for GitHub Copilot

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add instructions/sap-samples/hana-developer-cli-tool-example/translatable-text-handling
Clone the repo
git clone --depth 1 https://github.com/SAP-samples/hana-developer-cli-tool-example

Made for: GitHub Copilot.

Per session 2,470 This file is loaded in full into every session.
When invoked 2,470 The same file — it is already loaded in full.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.02470 $0.02470
Opus 5 $0.01235 $0.01235
Sonnet 5 $0.00494 $0.00494
Haiku 4.5 $0.00247 $0.00247

Measured 3d ago against content hash e2d5eab8c22f, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

hana-developer-cli-tool-example translatable-text-handling.instructions.md scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.github/instructions/translatable-text-handling.instructions.md · 304 lines

How it starts

The opening of the file, as written. The whole thing — 304 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Translatable Text Handling Guidelines

Use this guide whenever you add, update, or reference user-facing text strings in CLI commands, API routes, utilities, or any user-visible output.

Core Principle

All user-facing text must be translatable. Never hardcode strings that users see. Always use bundle.getText(key) to retrieve text from the appropriate i18n properties file.

When to Translate

Always translate:

  • Command descriptions (describe)
  • Option and parameter descriptions
  • Help text and error messages
  • Console output, responses, and logging for end-users
  • UI labels and status messages
  • Validation error messages
  • Success/warning/info messages

Do NOT translate (keep as inline strings):

  • Internal debug messages (prefixed with debug())
  • File paths and system constants
  • Technical identifiers (command names, option names)
  • Variable names and code structure
  • JSON keys and data structure identifiers

Example: What to Translate vs. What Not To

// ✅ CORRECT: User-facing text is translatable
export const describe = bundle.getText("backupCommand")  // "Create a database backup"
export const builder = (yargs) => yargs
  .option('schema', {
    describe: bundle.getText("backupSchema"),  // "Target schema for backup"
    type: 'string'
  })
  .example('hana-cli backup full', bundle.getText("backupExampleFull"))

// ❌ INCORRECT: Hardcoded strings not translatable
export const describe = "Create a database backup"  
export const describe = `Show ${tableName} schema`  // Dynamic content hardcoded

// ✅ CORRECT: Dynamic content with translation
const message = bundle.getText("backupComplete", { schema: schemaName })
// key: "backupComplete=Backup completed for schema {0}"

Import Pattern

Always import bundle from the correct base utility. The import source depends on your module type:

For CLI Commands (bin/*.js)

// In command setup (synchronous context):
import * as baseLite from '../utils/base-lite.js'
export const describe = baseLite.bundle.getText("commandKey")

// In async handler or functions:
const base = await import('../utils/base.js')
const message = base.bundle.getText("messageKey")

Read the full file on GitHub · 304 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 3d ago First seen · 304 lines · 2,470 tokens per session scan A e2d5eab8c22f

Subscribe to this mod's changes

hana-developer-cli-tool-example translatable-text-handling.instructions.md is an instructions file published in the GitHub repository SAP-samples/hana-developer-cli-tool-example (109 stars, last pushed 7d ago), licensed Apache-2.0. It adds 2,470 tokens to every session, about $0.0123 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.