OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [cti] i18n (RE: MVP Discussion) - An Updated Proposal

Hi, Trey,

Thank you for your comments. What I am trying here is not to break the standards
or anything, but to add as large added value as possible with as little change as
possible to the best of my knowledge and experiences. 
The value is relative from people to people and I too am biased living
outside of the English-speaking world for most of my life. 
However, incorporating i18n into the CTI standard at this point in the best
way possible (which may or may not be my current proposal) will add, 
I believe, a great value to the standards and make them future-proofed. 

> Ryu, would you be willing to lead the i8n working group?

I am not exactly sure what is involved, but yes, I would if there is 
a reasonable okay within the community. 
I truly believe doing i18n in a correct way is important for smooth
international CTI sharing to happen and I will do pretty much anything 
to contribute to it.

One caveat is that I am about to leave the office now 
for the Golden Week (https://en.wikipedia.org/wiki/Golden_Week_(Japan)) 
and that I will be off-line for a week. (I will be back in office 5/6 (Fri) JST.)

I will be attending the April CTI TC Meeting from 12:00AM JST tonight, though...



-----Original Message-----
From: Trey Darley [mailto:trey@soltra.com] 
Sent: Thursday, April 28, 2016 6:18 PM
To: Masuoka, Ryusuke/益岡 竜介
Cc: Jordan, Bret; John-Mark Gurney; Wunder, John A.; Mates, Jeffrey CIV DC3/DCCI; cti@lists.oasis-open.org
Subject: Re: [cti] i18n (RE: MVP Discussion) - An Updated Proposal

On 26.04.2016 06:21:05, Masuoka, Ryusuke wrote:
> One thing I do not understand, however, is that there seemed to be a 
> deep-rooted objection against "lang tag on each string field".
> Making text fields self-contained will be simpler and an enabler for 
> many things (here already and to come) and dependence on object 
> structure will, I am afraid, limit utility and flexibility of i18n.

Ryu is right on the money here, y'all. Let's be realistic, we're not talking about putting a lang property on *every* field in STIX; it only makes sense to translate a handful. Title, description...maybe a handful of others, but we're not talking about the entire data model.

In all my years living abroad, the majority of my friends (outside infosec, of course!) have been professional translators. I even worked for a translation agency myself, years ago. Professional translators generally use tools that leverage a database of previously translated text. The DRY principle is *not* constrained to the world of software development!

Ryu's approach aligns with the way professional translators actually work. In my view, it provides a robust i8n solution at the cost of adding a couple of bytes. The TC has a latent yet strong English-first bias; we should not lightly discount Ryu's reasoning!

I propose that we spin up an i8n mini working group. That group should identify all the fields in the data model that it would conceivably make sense to translate. This would enable us to make a reasoned estimate how many bytes Ryu's approach would cost and take an evidence-based decision.

Ryu, would you be willing to lead the i8n working group?

Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430 Soltra | An FS-ISAC & DTCC Company www.soltra.com
"For all resources, whatever it is, you need more." --RFC 1925

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]