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


Solutions like this do not allow for third party translations.. If you do all of the translations inside of the TLO, then you are saying, by definitions, that only the original producer (object creator) can generate the translation. 

I think what you are doing would be a great option, and is very similar to what we are proposing.  We are just using a hash-lookup table instead.


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Apr 25, 2016, at 10:07, Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu> wrote:

On 25/04/16 17:17, Jordan, Bret wrote:
So the bridge we need to decide if we need and want to cross is, should we allow mixed language content in a single STIX object.?

We haven't followed all the discussions about the mixed language content in STIX objects but we had some discussions
at implementation level. Increasing the complexity of the STIX object with the translation might not be the
most appealing aspect for developers who want to implement the standard... but why not using a gettext PO[1] approach?
Where the key is the original string and the value the translated part like this:

{
 "translation": [
   {
     "fr": {
       "Dridex malicious payload": "Dridex charge utile malveillante"
     },
     "ne": {
       "Dridex malicious payload": "Dridex खराब पेलोड"
     }
   }
 ],
 "id": "package--44af6c39-c09b-49c5-9de2-394224b04982",
 "lang": "en",
 "type": "package"
}


This would separate the parsing requirement for the implementations not supporting the translation to simply discard the parsing requirement
while keeping a certain flexibility in the translation usage. Like showing the translation if the user preference is set
to 'fr' with a fall-back to the original one.

The translation can be applied to any of the value encounters in a package including any specific value like tagging, description or alike.

We are evaluating this option for the new MISP galaxies representation.

Just an idea.

Cheers.

[1] https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html

--
Alexandre Dulaunoy
CIRCL - Computer Incident Response Center Luxembourg
41, avenue de la gare L-1611 Luxembourg
info@circl.lu - www.circl.lu

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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