Repository navigation
Add a Selecting on Language section, 'inLanguage' property. - #89
dmitrizagidulin wants to merge 3 commits into
Conversation
| <tr> | ||
| <td>targetLanguage</td> | ||
| <td> | ||
| An OPTIONAL [=string=] that designates a language range this render method is | ||
| meant to support (see the<a href="https://www.w3.org/TR/international-specs/#lang-matching">Matching | ||
| language and language tags</a> section for more details). | ||
| </td> | ||
| </tr> |
There was a problem hiding this comment.
I think this isn't well optimized for either scalability or privacy. I think it would be better for the payload to have language information, so every client fetches the same payload and then makes the language choice privately on the client. I think this would also avoid making issuers list many different render methods, one per language.
There was a problem hiding this comment.
The idea is exactly that -- it's specified once at issuance, and the selection is made on the client. The privacy considerations of fetching external payloads is a very valid concern, but it's part of the overall render method threat model (it's not specific to language).
There was a problem hiding this comment.
It seems that payload size has to come into play somewhere, like using ConNeg to GET a representation in only one language, instead of one representation including all of the "approximately 7,170" (!!) "living languages spoken in the world today".
Yes, privacy considerations are in play, but there has to be a balance between concerns!
Signed-off-by: Dmitri Zagidulin <dzagidulin@gmail.com>
Signed-off-by: Dmitri Zagidulin <dzagidulin@gmail.com>
dmitrizagidulin
changed the title
16e1fe3 to
34b599a
Compare
Signed-off-by: Dmitri Zagidulin <dzagidulin@gmail.com>
There was a problem hiding this comment.
Objection to the inLanguage feature as it stands right now, it feels like we're re-designing Accept-Language and we don't have the expertise to do so in this group (right before CR). What we could do as an alternative:
- Document that digital wallets are expected to have a default language or preferred language array.
- Document that those languages are passed into the HTML Render Method so it can make rendering decisions based on language (the suggestion being that this solves ~80% of the use cases). This provides some level of privacy protection to the individual because common languages can be bundled together in the same HTML template.
- Document that those languages are passed to any fetch of an external resource if the protocol scheme supports it (such as Accept-Language via HTTP).
Partially addresses issues #26 and #67
Preview | Diff