Skip to the content

Languages

The two language settings of the HTS Pilot API - Accept-Language for labels and messages, and the answer language of a lookup, set with the language field of a classify request.

Two settings decide the language of what the API returns. Accept-Language is per request and governs labels and messages. The answer language is per lookup and governs the text written for that lookup.

Supported languages: English (en), Vietnamese (vi), Japanese (ja) and Korean (ko).

Send Accept-Language with one of the four codes. A tag with a region is read by its language (en-US is en), quality values are honoured, and the first supported language wins. Without the header, or with no supported language in it, the service answers in its default language. The answer names its language in Content-Language.

curl https://htspilot.com/api/lookups/bcb6a35ae2694828b191f78ed704a9a9 \
  -H "X-API-Key: hts_EXAMPLE_KEY_REPLACE_ME" \
  -H "Accept-Language: ja"

What follows Accept-Language:

  • error messages (detail);
  • status and decision labels (status_label, decision_label), role labels, country names;
  • review flags: the message of each entry of review_flags and of result.flags;
  • the names of the checks, the disclaimer and the legal notes of a result;
  • the Excel templates and the Excel results of a batch.

The machine values next to a label do not change with the language: status, decision, the code of a review flag. Branch on those, show the labels.

A lookup has a language of its own, returned as language. It is set when the lookup is created:

  1. the language field of POST /api/classify, when it is sent (en, vi, ja or ko; a tag with a region is read by its language);
  2. otherwise the language of the request, from Accept-Language.

A rerun (POST /api/lookups/{lookup_id}/rerun) keeps the language of the lookup it continues, unless the request names another language.

curl -X POST https://htspilot.com/api/classify \
  -H "X-API-Key: hts_EXAMPLE_KEY_REPLACE_ME" \
  -H "Content-Type: application/json" \
  -d '{"description": "Stainless steel vacuum flask, 500 ml", "market": "US", "language": "ko"}'

What is written in the answer language, for every reader, whatever their Accept-Language:

  • the written reasons for choosing or ruling out a code, the summary and the open uncertainties;
  • the missing information (missing_info);
  • the questions with their options (result.questions);
  • the legal findings and the warnings.

So a lookup created in Korean reads in Korean to everyone, while its review flags and status labels appear in the language of whoever reads it.

Part of a lookup Follows
status_label, decision_label The reader (Accept-Language)
review_flags, result.flags The reader
Names of checks, disclaimer, legal notes The reader
Reasons, summary, uncertainties The lookup (language)
missing_info, result.questions and their options The lookup
Legal findings, warnings The lookup
Official tariff descriptions Not translated: as published

This changed: questions, missing information and legal findings used to follow Accept-Language on every read. A client that relied on the header for them now sets language when it creates the lookup.

Notes

  • A product description can be written in English, Vietnamese, Japanese or Korean, whatever the answer language.
  • Texts that live in the tariff data and the legal notes exist in Vietnamese and English; Japanese and Korean readers get the English text.
  • An integration that stores results for one team should set language explicitly on every classify request, so the stored text does not depend on the headers of whichever client created it.