Tutorials
Claude Opus 5.5: Parse Localized Product Numbers Without Guessing
Before asking Claude Opus 5.5 to repair imported product numbers, specify the input locale and accepted syntax.

Make it with Panelly
Turn inspiration into your next product ad
Bring a product image and an idea. Create a four-panel ad, a coordinated asset set, or a video with Panelly.
Create with Panelly Edit the brief before you generate.
Before asking Claude Opus 5.5 to repair imported product numbers, specify the input locale and accepted syntax. The string 1,234 can mean one thousand two hundred thirty-four or a decimal value, depending on that contract. A plausible-looking result is not evidence that the original value survived.
Preserve the text before conversion
A July 2012 community question describes parseFloat stopping at a thousands separator. MDN's parseFloat reference explains its longest-valid-prefix behavior. It is not a locale-aware validation step. Keep the raw cell, source locale and row identifier before normalization.
| Raw input | Declared contract | Expected normalized decimal |
|---|---|---|
| 1,234.56 | en-US grouping and decimal rules | 1234.56 |
| 1.234,56 | de-DE grouping and decimal rules | 1234.56 |
| 1 234,56 | fr-FR; U+202F grouping allowed | 1234.56 |
| 1,234 | Locale missing | Reject as ambiguous |
| 12,34.56 | en-US standard grouping required | Reject malformed grouping |
Check magnitude before arithmetic
Our local JavaScript fixture returns 1 for parseFloat('1,234.56'), 1.234 for parseFloat('1.234,56'), and 1 for the French example containing U+202F. These are observed parsing results, not Opus outputs. With explicit contracts, en-US 1,234 means 1234 while de-DE 1,234 means 1.234: a factor of 1000 separates them. Removing every comma and period would turn 1.234,56 into 123456, not 1234.56.
Intl.NumberFormat.formatToParts exposes pieces of formatted output; it is not a universal inverse parser. Define allowed digits, grouping, decimal separator, signs and scale. Decide explicitly whether currency symbols, exponent notation and surrounding spaces are allowed. Reject unsupported input instead of guessing. Retain a canonical decimal string until the downstream exact-decimal calculation step; do not confuse a formatting preview with proof of correct parsing.
A prompt for the import boundary
Review these raw product-number cells with row IDs and declared locales. Do not infer locale from one punctuation mark. Preserve every original string and return a separate normalized decimal string or an explicit rejection reason.
Before writing code, state the accepted digit set, grouping pattern, decimal separator, sign syntax, whitespace policy and maximum scale. Currency is a separate field unless the contract explicitly allows it. Reject missing-locale ambiguity, malformed grouping and unsupported symbols or exponent notation.
Return a small parser or a suitable existing parser with its supported scope, plus tests for all supplied rows. Include 1,234.56 under en-US, 1.234,56 under de-DE, U+202F grouping under fr-FR and the two rejection cases in the table. Compare magnitudes before any rounding. Do not overwrite input or change product prices. Mark unexecuted integration tests pending.
The official Opus prompting guide is the model reference. The proposed import repair has not been executed with Opus or against a production catalog.
Approve the normalized values
Review a manifest containing raw text, locale, normalized string and rejection reason. Verify accepted cases and deliberately invalid cases, then round-trip accepted values through the required display formatter. Formatting is a useful check, but acceptance still depends on the declared input grammar. Test the actual spreadsheet export and receiving importer before applying any catalog update.
**Can I remove all spaces?** Only those explicitly permitted as separators or padding; otherwise an invalid value may become valid-looking. **Should I round during parsing?** Keep parsing separate from the agreed calculation policy; the discount rounding guide covers that later step.
After the approved product facts are stable, create campaign images in Panelly Studio. This workflow does not claim a Panelly–Opus integration or automatic catalog correction.


