Re: [cti-stix] Supporting translations in STIX

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

I am not an expert on this at all, but looking at the registry it says "i-default" is "grandfathered", not sure if that implies "deprecated" or not (?)

http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

%%
Type: grandfathered
Tag: i-default
Description: Default Language
Added: 1998-03-10
%%

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Dave Cridland ---06/24/2016 04:23:58 PM---Allan, As I recall, "i-default" is "English for an International Audience" or some

From: Dave Cridland <dave.cridland@surevine.com>
To: Allan Thomson <athomson@lookingglasscyber.com>
Cc: cti-stix@lists.oasis-open.org, "Wunder, John A." <jwunder@mitre.org>
Date: 06/24/2016 04:23 PM
Subject: Re: [cti-stix] Supporting translations in STIX
Sent by: <cti-stix@lists.oasis-open.org>

---

Allan,

As I recall, "i-default" is "English for an International Audience" or some such. So it's English of sorts. I'm sitting on the sofa in post-brexit shock, however, and may not have that *quite* right.

In practise, "i-default" is either the C locale or US English I believe.

It's given as a special token to avoid a "better" English translation taking precedence.

Dave.

On 24 Jun 2016 20:18, "Allan Thomson" <athomson@lookingglasscyber.com> wrote:

I would prefer optional with a default of “English” value.

If anyone cares about which English version then suggest EU-English. (Had to make that joke based on Brexit news).

allan

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Date: Friday, June 24, 2016 at 12:06 PM
To: Dave Cridland <dave.cridland@surevine.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Supporting translations in STIX

Writing normative text would help us a ton, thanks! I think we need two things:


1.      The row in the property table:

Property Name

Type

Description

lang (optional/required)

string

?????



2.      A new 6.x section in the STIX Core document (sibling of versioning, object markings, etc.) with any other text we need (if any).

I would say we either make the field optional with a default of “i-default” or we make it required and force people to say what language they’re providing. We don’t want to tie STIX to TAXII but if there are transport considerations you think we should include at a more generic level we could do that in the 6.x section. I’d reach out to Bret and Mark on the TAXII side to include the Accept-Language stuff directly in those specs.

Thanks again,
John

From: Dave Cridland <dave.cridland@surevine.com>
Date: Friday, June 24, 2016 at 2:05 PM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Supporting translations in STIX


2(a) for now. I'm assuming a IANA language tag here, with a default of "i-default" (from memory).

I think translation objects will work, an alternate design might be to duplicate the entire object (reference and all), or have a relationship to indicate equivalent objects (which allows for both translations and more complex equivalences).

We'd want TAXII to mention something about Accept-Language for HTTP, and maybe note about other l11n capabilities in other transports (eg, stream language in XMPP), and payload formats (Content-Language in HTTP, email, and stanza language tag in XMPP).

I can knock out some formal normative text if you like.

Dave.
On 24 Jun 2016 16:28, "Wunder, John A." <jwunder@mitre.org<mailto:jwunder@mitre.org>> wrote:
All,

You’re probably aware that we’ve had a bit of work over the past couple months on the best approach to support translations in STIX. As I alluded to in the prioritization e-mail, it’s getting to the point where we need to decide on an approach or we’re at risk of not making the July release date and having to postpone until Winter. As I see it, we have a couple options.


1.       We can decide on a general approach and try to prove that it will work for MVP. Ideally, it would be a fairly minimalist approach so that we can be confident in the flows.

a.       Along those lines, I wrote up some normative text on an approach we discussed on Slack. Translations are very minimal objects (not standard TLOs) and refer to other TLOs to translate their titles and descriptions. It’s here: https://docs.google.com/document/d/1wiG6RoNEFaE2lrblfgjpu3RTAJZOK2q0b5OxXCaCV14/edit#heading=h.aq3spklsm9m6

b.       If we think that approach is close enough to agree on by MVP we can continue to evolve that.

c.       If you have a different approach that you think we can agree on, please write up some normative text and submit it to the full list.

2.       Alternatively, we can implement something super minimalist now and delay until winter (6 months) to make sure we get this right

a.       IMO if we add a “lang” property to all TLOs we can provide some immediate capability and build on it in the winter.

My preference at this point is #2a. Let’s just add a “lang” tag to TLO common properties, put the discussion on hold while we finish MVP, and then resume in August. Then we can spend the fall making sure we get it right. At the same time, we enable an ecosystem where TLOs are in specific languages and so people can innovate and try out different approaches. That said, if people think #1 is close, I’m happy to continue trying to push that forward.

What do you think?

John