[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-omos] A few notes in JSON and inline content
Hi Ryan, all, I think we are aiming at standardizing only the representation of the extracted data (in the XLIFF sense), no? The parts that are not extracted are typically “external codes” like <h1> in your example. Those parts are in the skeleton. So, using a more classic example (with an image instead of '[productname name="Acme Phone"]', but it's the same really): Alert: <h1><img src="phone.png" alt="Acme Phone"] now available in stores.</h1> Get it today! We would get 4 units: - 1 for the text before <h1> - 1 for the nested alt attribute - 1 for the content of <h1> - 1 for the text after <h1> With the Okapi HTML filter that would be represented like this: <unit id="tu1"> <segment> <source>Alert:</source> </segment> </unit> <unit id="tu3" type="okp:alt"> <segment> <source>Acme Phone</source> </segment> </unit> <unit id="tu2" type="okp:h1"> <originalData> <data id="d1">[#$dp1]</data> </originalData> <segment> <source><ph id="1" canCopy="no" canDelete="no" subFlows="tu3" dataRef="d1"/> now available in stores.</source> </segment> </unit> <unit id="tu4"> <segment> <source>Get it today!</source> </segment> </unit> So that means we have 4 separate JSON internal content items, not 1. Obviously that would be also serializable in JSON, as JSON units. The file would include probably an array of units. [ { // the first unit "id":"tu1", [ // the unit's segments { // the segment "source":{ // the source [ // the array of content objects "Alert:" // the plain text object ] } } ] }, { // the second unit "id":"tu3", "type":"okp:alt", [ // the unit's segments { // the segment "source":{ // the source [ "Acme Phone" ] } } ] } // etc. ] What about the "<h1>" between the two units? My view is that it would be stored as part of the skeleton JSON representation at the file level, if you have a skeleton. ... > How would I know, though, where to place </h1>? > So how about something even more explicit: That second representation with the two tags at the same level as their content looks closer to the non-nested one: I like it better. Cheers, -yves
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]