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
messageof each entry ofreview_flagsand ofresult.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:
- the
languagefield ofPOST /api/classify, when it is sent (en,vi,jaorko; a tag with a region is read by its language); - 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.
- 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
languageexplicitly on every classify request, so the stored text does not depend on the headers of whichever client created it.