[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Re: MVP Discussion
Personally, if we were to do i18n as MVP, I’d say let’s just put a “lang” field in the root of all STIX objects and be done with it. If the relationship types are extensible, people can start using a “translation-of” relationship if it makes sense. If
a theoretical “translation-of” relationship gets widespread use, we can integrate it into future releases of STIX.
IMO they key is to think of two TLOs with different “lang” fields as different representations of the same TLO, not two different TLOs. Thinking of them as different TLOs is, I think, getting us wrapped around the axle.
I think the example below would be perfectly valid. Note that the IDs are the same because they are the same report, just different representations of the same report.
[
{ "id": "report--cbf7a3eb-5ef0-42ef-a30c-14be2a14cc1d", "type": "report", "lang": "en", "created_at": "2016-01-29T21:18:33Z", "title": "Hi, this text is in English", "description": "So is this" }, { "id": "report--cbf7a3eb-5ef0-42ef-a30c-14be2a14cc1d", "type": "report", "lang": "es", "created_at": "2016-01-29T21:18:33Z", "title": "Hola, este texto es español", "description": "Asi es esto" } ] Thank you.
-Mark
From: <cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Friday, April 8, 2016 at 7:18 AM To: "Jordan, Bret" <bret.jordan@bluecoat.com> Cc: "Masuoka, Ryusuke" <masuoka.ryusuke@jp.fujitsu.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] Re: MVP Discussion Bret,
This way of doing translations causes the same problems as the explicit versioning... relationships no longer point to the latest version of an object (as there may be two translations of the same object). Which object is the 'truth'? Which version of
the object is the one that everyone should connect their relationships to?
An alternative is to make all 'free-text' fields an array of text entries, and each text entry has a language attribute associated with it, so that the single object embeds multiple languages. But then this has its own problems, that there is no way for
third-parties to provide a translation of another companies data (maybe that's a good thing as it isn't officially published by them)?
Another alternative would be to actually create a Translation object. This would then be used only in a translations of other objects. This would mean there is only one 'real' version of an object, and the others are specifically translations, meaning
there is no confusion as to which one is the true assertion. In other words something like this:
[
{ "id": "report--cbf7a3eb-5ef0-42ef-a30c-14be2a14cc1d", "type": "report", "lang": "en", "created_at": "2016-01-29T21:18:33Z", "title": "Hi, this text is in English", "description": "So is this" }, { "id": "relationship--7f3fcd28-9a4b-480b-852b-77e7b33db237", "type": "relationship", "source_ref": "report--cbf7a3eb-5ef0-42ef-a30c-14be2a14cc1d", "target_ref": "translation--5cfa580e-ea87-4d11-b0cc-600af7a64968", "bidirectional": true, "value": "translation-of" }, { "id": "translation--5cfa580e-ea87-4d11-b0cc-600af7a64968", "type": "translation", "translated_type": "report",
"lang": "es", "created_at": "2016-01-30T19:13:09Z", "title": "Hola, este texto es español", "description": "Asi es esto" } ] Maybe that could work?
Cheers
Terry MacDonald | Chief Product Officer
On Fri, Apr 8, 2016 at 8:01 AM, Jordan, Bret
<bret.jordan@bluecoat.com> wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]