Re: [community-group] Are token descriptions optional or required? (#62)

Excellent points about supporting i18n and how JSON-LD could provide an established means to do so. Thanks @delisma and @duboisp for bringing these points to our attention!

I do wonder if basing our design token format on JSON-LD might add more complexity than we need. Based on the examples in @duboisp's comment and a brief skim of the JSON-LD spec, it looks like there are potentially quite a few different ways of expressing the same data by using (or not) `@context`. While it's pretty nifty, I wonder if it would steepen the learning curve for anyone wanting to manually read/write design token files. They'd need to familiarise themselves with JSON-LD as well as whatever design token specific conventions (or would that be a context or vacabulary?) we layer on top of it.

If I've understood JSON-LD correctly (and please do correct me if I haven't!), we may also need to re-think to how we express the data model described by our design token format. As it stands our design token format describes a fairly basic tree structure with 2 kinds of nodes: groups and tokens. Tokens are always leaf nodes and groups can have tokens and/or other groups as child nodes. That parent-child relationship is implicit in the nesting of JSON objects. Can we do that in JSON-LD? Or would we need to define some kind of explicit "child of" /"parent of" predicate that needs to then be used?

However, be it by using JSON-LD or creating our own mechanism, I am wondering if we need a means for internationalized text values not just for `description` but any token or group property that has human-readable text as its value. The current spec draft doesn't list any other than `description` right now, but there has been talk of adding things like deprecation notes in the future and I could imagine being able to provide those in more than one language could be handy too.

Going back to @delisma's original suggestion (which is also very similar to the last JSON-LD example in @duboisp's comment) I wonder if could simply say that the value of a description (and any other props with human-readable text values we may add in future) can be either a JSON string or a JSON object whose properties are language identifiers and corresponding values are strings. E.g.:

```json
{
  "token 1": {
    "value": 123,
    "description": "I am a description whose language has not been explicitly identified"
  },
  "token 2": {
    "value": 321,
    "description": {
      "en": "I am an English description",
      "de": "Ich bin eine deutsche Beschreibung"
    }
  }
}
```

-- 
GitHub Notification of comment by c1rrus
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/62#issuecomment-969385732 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 15 November 2021 22:33:37 UTC