I’m not on jmap list, but I have to say that their proposed approach is much more complicated to decode by standard json decoders. I would say don’t do it.
Marc. > Le 21 juill. 2021 à 08:50, Mario Loffredo <[email protected]> a écrit > : > > I would like to invite the WG members to provide feedback about a topic that > might impact on future RDAP implementations. > > If you are interested, please reply on JMAP mailing list. > > Any contribution is welcome. > > Thanks a lot, > > Mario > > > > -------- Messaggio Inoltrato -------- > Oggetto: [Jmap] JSContact: how to localize content > Data: Wed, 21 Jul 2021 14:12:38 +0200 > Mittente: Robert Stepanek <[email protected]> > <mailto:[email protected]> > A: [email protected] <mailto:[email protected]> > > At the joint CALEXT/JMAP interim meeting > <https://datatracker.ietf.org/doc/minutes-interim-2021-jmap-01-202104150300/> > in April we discussed options how localize JSContact values. This can be > useful to provide names and addresses in multiple languages within the same > contact. In VCARD this is achieved with the LANG parameter. > > We would now like to find consensus how to achieve this in JSContact. > > Current approach > The current scheme in the spec defines a LocalizedString object for fields > that can be localized. A LocalizedString has a value and optional localized > variants of this value: > "addresses": { > "addr1": { > "city": { > "value": "Tokyo", > "localizations": { > "jp": "東京" > } > } > } > } > The idea is to keep values and their localizations close. It is built on the > assumption that the majority of values will have localized variants. > > Proposed approach > Multiple participants in the interim meeting vouched for replacing the > current approach with the one defined in section 4.6.1 > <https://datatracker.ietf.org/doc/html/rfc8984#section-4.6.1> of the > JSCalendar RFC. That is, the "localizations" property is a JSON object where > the keys are language tags, and the values are patch objects which overwrite > one or multiple properties within a contact. > > A main benefit of this is to reuse for the same approach in both JMAP > calendars and contacts. It treats localized content as the exception, not the > norm, and the data types should reflect this. Any property value can be > localized (except if the spec explicitly forbids it). In contrast, only > values of LocalizedString can be localized in the current approach. > > This an example how to localize a single address field: > "addresses": { > "addr1": { > "city": "Tokyo", > } > }, > "localizations": { > "jp": { > "addresses/addr1/city":"東京" > } > } > To fully localize an address, one would write: > "localizations": { > "jp": { > "addresses/addr1": { > "city": "東京" > } > } > } > > > Finding consensus > Mario and I would now like to know which approach you prefer, or any other > you would like to propose. Our goal is to reach clear consensus. We look > forward to your feedback. > > Thanks, > Robert > <Parte allegato al > messaggio.txt>_______________________________________________ > regext mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/regext > <https://www.ietf.org/mailman/listinfo/regext>
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
