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

[Trey Darley <trey@soltra.com>]

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?

-- 
Cheers,
Trey
--
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

Attachment: signature.asc
Description: Digital signature