Localization prompts: render typed dates, numbers, and units

Last updated: 5 Oct 202611 min read

tutorial

A model should not retype a timestamp, quantity, or currency amount into a locale-looking string and then use that string as data. Give it a typed value, its unit or time zone, the target locale, and the intended display role. The application formatter performs rendering; the prompt reviews the result and flags ambiguous labels. A date-only delivery promise differs from an instant in time, and a currency symbol without a code may be unclear across regions. Preserve the machine value and the rendered value together for audit.

Operational case

HP-29 shows a delivery instant with a numeric date that could be read in two orders. Harbor retains the underlying timestamp and reporting time zone, then asks the formatter to render a target-locale label. The review compares that label with the schedule confirmation and checks whether the day boundary changed correctly. It does not ask a model to guess an instant from an ambiguous source string. A count of 47 parcels likewise stays numeric until the display layer formats it.

HP-29 input: typed delivery instant + explicit time zone
Display: target-locale date and time from formatter
Audit: retain instant and rendered label together
Reject: ambiguous numeric date parsed by guesswork

Performance and review cost

Formatting N independent values is O(N) application work; testing boundary instants adds a small fixed set per time zone. Keeping typed source fields costs storage but prevents repeated parse errors. The review prompt should spend its tokens on display ambiguities and missing context, not on manual recalculation the runtime can perform consistently.

Common Mistakes

Do not parse an ambiguous date without an explicit source format.
Do not use localized display text as a stored numeric value.
Do not drop the time zone from an instant-based promise.

Connected lessons

prompt engineering

localization quality