beckn / beckn/protocol-specifications-v2

No support for localizing authored content (multilingual name/shortDesc/similar fields)

Open
#192 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
15
Forks
13
PR merge metrics
No merged PRs in 30d

Description

**Background**

[Fabric-support #96](https://github.com/Networks-for-Humanity/fabric-support/issues/96) (ION) flagged that `Descriptor` only supports single-language strings for `name`/`shortDesc`/`longDesc`. Their workaround, `LocalisedText`, duplicates those fields rather than solving the problem at the attribute level.

The spec already has a documented position on localizing **terminology** — NFO-specific `context.jsonld`/`vocab.jsonld` aliasing into canonical IRIs (see [Schema Design Guide §"localize a Beckn network"](docs/Schema_Design_Guide.md#L614)). That mechanism fits enumerated/coded fields (statuses, categories, unit codes): the code stays a stable identifier, and its display label is resolved externally per language.

It does not cover **authored content** — free text written per-record, in more than one language, by whoever lists the entity (product names, descriptions, media labels). There's no external vocabulary to alias into here, because the content itself differs per instance, not just per language.

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the Descriptor fields and the Schema Design Guide section on localizing a Beckn network, then compare that terminology approach with the authored content fields named in the issue. Done requires a decided, documented specification approach for representing multilingual name, shortDesc, longDesc, and similar per-record content.

Written by the indexing model from the issue text.

Assessment

Domain
api
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.