eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

How People Translate Quickly | STIX 2.1 Language Content: Translate Threat Reports Without Changing Indicators

—

by

eduKate Asia

To translate STIX 2.1 threat intelligence quickly, create or review a language-content object that supplies human-language alternatives for approved properties while leaving the original threat-intelligence object intact. The translation should point back to the source object using object_ref and, when a specific revision matters, object_modified. Preserve machine identities, indicator patterns, timestamps, relationships and markings as data. Translate what an analyst reads to understand the threat, not the evidence a detection tool evaluates.

STIX Language Content quality assurance is different from translating a plain PDF threat report. A PDF can be edited and reviewed as prose; a STIX bundle is a graph of referenced objects, relationships and machine-readable assertions. A localized description that silently changes the asserted actor, scope, time period or confidence can mislead a security team even if every JSON field remains valid. A localization pipeline therefore needs both structural validation and a reviewer who understands how the translated text will support real operational decisions.

This guide explains the source-to-translation process for security educators, analysts, intelligence-sharing teams and technical translators. It focuses on one canonical reader job: making an existing STIX 2.1 object understandable across languages without changing the underlying object or its references. It includes a small example, version-pinning logic, handling of arrays and markings, failure diagnostics, an answerable transfer exercise and a release checklist. It does not teach offensive techniques or turn translation into a pretext for changing security evidence.

Why STIX is a graph rather than a document

Structured Threat Information Expression represents cyber-threat knowledge as structured domain objects, cyber-observable objects, relationship objects and related metadata. A report can refer to indicators, attack patterns, malware, identities and other objects by stable identifiers. Applications may use those links for search, graph analysis and incident triage. Human descriptions help readers make sense of the graph, but they do not define every machine relationship. Editing a description in one local view should not cause a relationship to point to a different actor or an indicator to match a different pattern.

The distinction is particularly important when multiple teams share information. A regional incident response team might need a Japanese explanation while another organization uses the same object graph in English. Both should be able to discuss the same indicator identifier and source assertion. If localization creates a second, independent threat object merely to hold translated prose, consumers can mistake it for a new intelligence claim. STIX Language Content exists to carry alternative language without automatically replacing the object being described.

A reliable reader interface must also show whether it is displaying original wording, a publisher-supplied translation or a third-party translation. The STIX specification allows language content from different sources, but trustworthiness is not guaranteed by the object type. A translated summary can be wrong or outdated. Provenance and review status should therefore be visible in local workflow metadata or a trusted publication process, especially when translated material influences security decisions beyond a classroom example.

Locate the exact source object before translating

Begin by recording the source STIX object type, id, spec_version, created, modified and the content fields under review. Read the object in the context of its references and data markings. A campaign description may refer to relationships or other named objects whose identities are not contained in that one sentence. Translators who see isolated field values may resolve pronouns or technical terms incorrectly. Provide the minimum contextual graph needed to understand the claim without unnecessarily exposing sensitive intelligence.

A human-friendly title is not an adequate source key. Two STIX objects may share the same name while referring to different activity, organizations or revisions. Use object_ref to connect the language-content record to a specific object identifier. If the target is a later version of that object, review whether the existing translation still applies. The optional object_modified property has a defined version-identifying role when supplied; treat it as a meaningful source-revision link rather than harmless metadata that a publishing script can reformat.

Record which source fields are genuinely translatable. Typical candidates are explanatory name and description strings where the object’s rules allow them, or text in an appropriate list field. Indicators and object identities are not candidates for word translation. When a domain object has fields with defined enumeration semantics, do not substitute a local-language synonym into the machine slot. The source should supply exact field classification, because a generic rule that translates every JSON string is almost certain to cross the wrong boundary.

Understand the language-content object’s own identity

A Language Content object has type equal to language-content, its own STIX identifier, creation and modification timestamps, and a contents dictionary keyed by language tags. It refers to the original object with object_ref. Importantly, contents is not an arbitrary glossary or a new STIX object definition. Each localized field should correspond to a translatable field on the referenced source, with the value shape required by the specification. This is a representation of alternate text, not permission to invent new source properties.

The nested language keys follow RFC 5646 language-tag conventions. A language tag is a machine label identifying the language of a translated value. It should not be translated into a target-language word. A localized user interface can display a reader-friendly language name, but the dictionary key must remain a valid expected tag. Avoid ad hoc labels such as Spanish Version or Mandarin translation as machine keys. Consistent tags support filtering and fallback across teams that use different software implementations.

Do not conflate the source object’s lang property with the Language Content object’s top-level properties. The STIX 2.1 specification distinguishes the language on a source object from the contents map on a Language Content object, and lists lang as not applicable to the latter’s common properties. A pipeline that copies every common property from a domain object into the language-content record may produce an invalid or misleading object. Use the schema for the exact STIX object type, not a one-size-fits-all JSON template.

Source versions matter because words change

An intelligence object can be revised without receiving a completely new identifier. Its prose might be updated after a new investigation, a mistaken attribution might be corrected, or a time-window claim might be narrowed. A translation prepared for the earlier wording should not automatically be treated as an accurate rendering of the revised object. When object_modified is set, it must exactly match the referenced object’s modified timestamp. That is a practical version-binding signal, not just a date shown to readers.

Imagine that an original description says a cluster ‘may have used’ a specific tool, while a revision later says an observed technique remains unattributed. Retaining a target-language translation from the first version would keep pointing readers toward an attribution the source no longer makes. A well-designed update workflow compares source revisions and places affected translations into review. It does not refresh timestamps on old translations simply to make the records appear current.

The safest catalog stores a source-text digest and translation review state alongside its language-content object in an editorial system. A digest is not a normative STIX property that every consumer will understand, so keep such workflow metadata in an appropriate external manifest or defined extension. This lets release QA verify that the approved target still corresponds to the intended source content. Reviewers can then focus on meaningful changes rather than re-reading every unchanged explanation on each distribution cycle.

Preserve indicator patterns and observable values

Indicator patterns and cyber-observable values can drive automated detection and investigation. Altering a pattern as part of localization can change which evidence matches. A technical term embedded in pattern syntax is not a word that becomes more correct when translated into the local language. Lock the pattern, its comparison operators and field paths out of the translation interface. Human explanatory text can describe what a pattern means at a high level, but the machine expression remains the source’s own structured assertion.

Be similarly careful with hashes, URLs, domains, IP addresses, registry paths and file names when they appear as quoted evidence in a description. Some are identifiers to preserve literally; others might be sanitized placeholders in a teaching example. A translator should know which role each span plays. Do not convert a technical artifact into local punctuation, change letter case without reason or rewrite an identifier to make it easier to pronounce. Those changes can mislead readers even when they happen only in prose.

A release comparison should include structural equality for the source objects and check that the translation object contains only approved textual alternatives. If a bundle editor accidentally changed the indicator in the same transaction, the translation batch must fail. The team needs a clean boundary between source intelligence revision and language enrichment. Security intelligence may legitimately be updated by analysts, but that requires its own evidence and approvals. Treat translation as an independent layer whose success does not imply authorization to revise intelligence.

Treat confidence and attribution words as evidence claims

Cyber-threat reports often express degrees of confidence rather than certainty. Terms such as ‘possibly’, ‘likely’, ‘suspected’, ‘associated with’ and ‘observed’ are not interchangeable. A rushed translation can collapse them into a definitive accusation, or soften a strong evidence statement into vague rumor. Both changes are harmful. Make a domain glossary of confidence expressions and provide the translator with the surrounding evidence context. When a wording decision could affect attribution, a competent intelligence reviewer should approve it before distribution.

STIX has structured properties such as confidence on certain objects, but the existence of a numeric or enumerated field does not mean a prose claim can be freely rewritten. Preserve the structured value and its relationship to the text. If a target sentence says an actor is certainly responsible while the source field communicates limited confidence, the localized report has become internally inconsistent. Reviewers should read the displayed output as a security analyst would, not just compare two strings word for word.

Attribution also has legal and social consequences. Incorrectly translating an organization’s role in an incident can unfairly implicate people or encourage an inappropriate response. Present third-party translations as translations, not authenticated source assertions, and keep the original accessible where sharing rules permit. If a technical term or actor label is ambiguous, flag it instead of inventing specificity. Useful localization makes uncertainty legible; it does not hide gaps in intelligence behind smooth prose.

Markings and sharing restrictions remain authoritative

STIX data markings describe permissions and restrictions on use or sharing. These may apply to whole objects or granular properties and can affect whether a translation may be distributed at all. A translator should not assume that a source can be copied into any external service simply because its format is standardized. Before exporting text, determine the applicable markings, agreements and handling rules. The local-language version may contain the same sensitive facts as the original and generally needs equivalent treatment.

Do not translate marking identifiers into improvised values or drop marking references because they look cryptic. If the publishing workflow needs a friendly explanation of a sharing restriction, provide a reviewed target-language display sentence while preserving the underlying policy reference. An accessible warning is useful only if its meaning and operational consequences match the governing rule. A renderer should also avoid suppressing warnings when a translated view is selected; language choice must not silently weaken a handling requirement.

There is a second, more subtle risk: an external translation vendor may receive fragments that, individually, appear harmless but collectively reveal a sensitive campaign or investigation. Apply data minimization and organizational approval before sending materials outside a controlled environment. This is not merely a cybersecurity concern but a localization process concern. A safe workflow can provide translators with necessary context while restricting access to unrelated observables or personally sensitive details. Record the access decision so later reviews can understand how the translated material was prepared.

Lists require positional discipline

STIX language-content handling of lists has a specific rule: the translation list must correspond positionally to the original list and have the same length. If only some items are translated, an empty string acts as a placeholder for an untranslated position. A common mistake is to drop an empty item or sort the translated items alphabetically because the result appears tidier. That changes which translation belongs to which original element. The correct approach is to preserve list length and order in the language-content representation.

Suppose a threat actor object has two human-readable goals. The translator can provide a target for the first while leaving the second represented by an empty string. That is not the same as supplying a one-item list and expecting the renderer to guess alignment. A validator should compare source and target array lengths and ensure that translated elements have the expected value types. A consumer can then interpolate untranslated source items according to the specification. The reviewer must still decide whether mixed-language display is appropriate for the audience or whether a complete translation should be required before release.

Nested objects require similar structural fidelity. When a translated value mirrors an object-valued source property, its keys and nesting should correspond to the source location. Do not flatten the structure into a sentence field or introduce an unrelated key simply because the translation editor exports a convenient format. A JSON parser may accept arbitrary nested dictionaries, but a STIX consumer may ignore a translated path that does not refer to an existing translatable property. Semantic path validation is therefore distinct from syntactic validity.

A small, valid-shape teaching example

The following JSON illustrates the relationship between a synthetic source campaign and a French translation. The identifiers use UUID-shaped teaching values and should not be interpreted as operational intelligence. The description deliberately describes a fictional classroom scenario without supplying offensive procedures or indicators. The example can be parsed as JSON; full STIX schema validation and project-specific consistency checks remain separate tasks.

[
  {
    "type": "campaign",
    "spec_version": "2.1",
    "id": "campaign--11111111-1111-4111-8111-111111111111",
    "created": "2026-01-01T00:00:00Z",
    "modified": "2026-01-01T00:00:00Z",
    "lang": "en",
    "name": "Training Scenario",
    "description": "Fictional example used to practise reading intelligence confidence."
  },
  {
    "type": "language-content",
    "spec_version": "2.1",
    "id": "language-content--22222222-2222-4222-8222-222222222222",
    "created": "2026-01-02T00:00:00Z",
    "modified": "2026-01-02T00:00:00Z",
    "object_ref": "campaign--11111111-1111-4111-8111-111111111111",
    "object_modified": "2026-01-01T00:00:00Z",
    "contents": {
      "fr": {
        "name": "Scénario de formation",
        "description": "Exemple fictif utilisé pour apprendre à lire le degré de confiance d'un renseignement."
      }
    }
  }
]

Notice what remains stable. The source campaign retains its own identifier, timestamps, source language and original description. The translation has a different identifier, points to the campaign and supplies French prose under a language tag. The contents dictionary mirrors the original field names rather than translating name into a French JSON key. A classroom validator can check that both identifiers have the right type prefixes, that the reference exists and that the pinned source timestamp agrees. The language reviewer then decides whether the French sentence communicates the source’s educational purpose without making a new threat claim.

This example does not claim that an array of two objects is a complete STIX bundle, nor does it show every possible versioning or marking requirement. A production publisher should create the appropriate bundle and validate with the intended implementation and specification profile. The purpose here is to teach what belongs in the language-content layer. An example that is syntactically neat but silently mutates the source campaign would demonstrate the wrong lesson, even if a quick demo tool rendered it without complaint.

Build an extraction table around field paths

A practical extraction ledger records source object id, exact modified timestamp when applicable, property path, source text, language target, reviewer, source markings and review status. Its field-path column should refer to actual translatable source properties. Do not use row number as the only identity: exporting and resorting a spreadsheet can otherwise attach a translated description to a different threat object. The importer should reject any target row whose source reference or source-text digest does not match the snapshot under review.

Keep technical values out of the translator’s writable columns. The translator may need to see an indicator’s high-level meaning or surrounding report context, but source object IDs and patterns can be shown read-only or through controlled hints. If a domain term has several possible translations, provide disambiguation notes tied to its STIX property and the local analysis workflow. This avoids confusing ‘campaign’ as a military operation in ordinary language with a precisely modeled cyber-threat campaign, or confusing an ‘indicator’ with a generic warning label.

For ongoing feeds, batch by review unit rather than by arbitrary file size. A complete object’s description and closely related notes are easier to translate accurately together than a list of unrelated strings. However, do not expose confidential linked objects that the reviewer does not need. Context must be sufficient but proportionate. A well-designed extraction stage removes dangerous editing possibilities while still supporting real semantic decisions; it does not solve complexity by leaving the translator blind.

Diagnose a translation that points to the wrong object

Suppose the local-language viewer displays a convincing explanation under the wrong campaign. Inspect object_ref first, then inspect whether the importer used an obsolete mapping from names to identifiers. The repair is to reconnect the language-content object to the exact intended source id, verify the referenced object exists and rerun source-text alignment. Do not simply rename the source campaign to match the translation. That would revise intelligence evidence to cover up a localization mapping error.

A related failure occurs when two objects share similar names. The extraction system may merge their translations because it treats names as unique keys. The correct fix is to key every translation by the STIX object identifier and relevant source revision. Then compare all emitted translations against their source fields, ideally with a second person’s review for ambiguous collisions. A duplicate-name audit is useful, but its purpose is to expose unsafe mapping logic, not to require artificially unique names that the source publisher never provided.

Diagnose stale language against a revised source

A translated description may be grammatically excellent and still obsolete. If a source object’s modified time changes, compare its relevant text and the translation’s pinned source version. A mismatch requires review before presenting the target as current. Do not silently rewrite object_modified to the latest timestamp; that would assert correspondence without verifying the wording. If the translation is still accurate, record the review and issue an appropriate updated language-content version according to the publisher’s lifecycle rules.

An analyst may need historic views for reproducibility. Preserve the earlier language-content object or its archived representation when the publication policy allows, and expose the applicable source revision. That way a team can reconstruct what a reader saw at the time of a decision. A public display can prefer current reviewed translations without erasing historical traceability. This is particularly valuable when an attribution changes because new evidence becomes available. Language review should not overwrite the sequence of evolving intelligence claims.

Diagnose missing list items after localization

If a translated list displays the wrong goal or skips a middle item, compare its length and position with the source. The STIX specification’s empty-string placeholder rule is more precise than a casual translation-memory system may expect. A generic editor may remove blanks on export or filter out untranslated cells. Restore explicit placeholders, keep the list length equal to the original and rerun rendering tests. If the same tool cannot preserve positional lists, it should not be used for this kind of source property without a protective adapter.

The display policy needs separate thought. A consumer may interpolate the original wording for a missing translation; the UI should make mixed-language content understandable rather than silently suggesting that every item has been reviewed. For safety-sensitive descriptions, an organization may choose to withhold an incomplete translated list and show the full authoritative source until the target passes review. The STIX data structure permits partial translation, but the editorial decision about whether partial translation is fit for a particular audience is not dictated by the mere existence of an empty string.

Diagnose lost markings or unintended disclosure

A target-language version appears on an unprotected public page even though its source has restrictive data markings. Stop distribution, identify the failed access path and check whether the localized renderer discarded marking references during transformation. Merely re-adding a translated warning after exposure is insufficient. The publication system must apply the same underlying sharing policy to translated content as to its source. Audit caches, exports and downstream consumers where the incident response policy requires it, and record the correction.

Prevent recurrence by checking markings before extraction and again before publishing. The translation workflow should not gain a separate permissive access rule merely because its objects are called ‘language content’. Include a realistic restricted test fixture in staging to show that the target page is withheld when the original is withheld. Use only non-sensitive synthetic data in training. This separates the reader’s need for accessible language from the organization’s duty to respect agreements governing shared intelligence.

Validation must combine schema, reference and semantic checks

Begin with JSON parseability and validation against an implementation of the relevant STIX 2.1 specification. Check required properties, identifier patterns, timestamps and the structure of language-content dictionaries. A valid JSON object is not automatically valid STIX, and a STIX-shaped object is not necessarily linked to a real source in the bundle. Make that distinction visible in reports. Each validation statement should name the scope and tool version rather than offering a vague badge saying ‘all checks passed’.

Next validate references. Resolve each object_ref against the target corpus and, when supplied, compare object_modified exactly with the target’s modified timestamp. Confirm every translated path exists on the original and is appropriate for translation. For lists, compare lengths and inspect placeholder positions. For nested objects, check structural correspondence. These checks can be automated and should run before a human language reviewer invests time in a broken mapping. A syntax error is cheaper to fix than a conclusion drawn from an explanation attached to the wrong threat.

Then verify that original objects have not been altered by localization. Compute canonical comparisons for identities, relationships, indicators, markings and scientific or security evidence fields according to the project’s representation rules. Avoid overclaiming byte equality if normal JSON key ordering or whitespace changes are expected; compare parsed values and relevant source snapshots instead. Any permitted source revision needs its own authorized change record. Translation approval cannot serve as implicit authorization for modifying a detection pattern or attribution object.

Finally conduct language and user-interface checks. Ask a qualified reviewer whether the target changes actor identity, confidence, time scope, evidence status, possibility or negation. Display the translated view in the actual security product, including narrow layouts and missing-translation fallbacks. Confirm that readers can reach source wording when policy permits, identify third-party translations and recognize incomplete localization. The most serious localization defect may be a confident but false sentence rather than a malformed file. Automated validators and bilingual security analysts therefore perform different, complementary work.

Translation memory for threat intelligence needs context

Security terminology is unusually context-sensitive. ‘Exploit’ can be a noun or verb, ‘campaign’ can describe coordinated activity, and ‘persistence’ has a technical meaning distinct from everyday determination. A translation memory entry should record object type, source property, context and reviewed target wording. Reuse is helpful when the same defined concept recurs, but a similarity percentage alone does not prove that two sentences express the same threat claim. If the source changes its level of certainty, mark the old target for renewed review.

Avoid using a dictionary replacement rule for object names. Some names are established proper names used across security communities; others are generic descriptions. An informal translated alias may be helpful in a local-language explanation, but it should not replace the canonical identity or create a second actor in a graph view. Work with analysts to decide whether to retain, transliterate or explain a name for a particular audience. Record the decision, so future translators do not create three inconsistent names for the same source object.

For repeated releases, distinguish terminology updates from intelligence updates. A glossary may evolve because a language community adopts a better technical term even when the source description has not changed. That is a translation revision. A source campaign may evolve because analysts discover new evidence. That is an intelligence revision. Keeping those histories separate lets an organization understand why text changed and whether a decision should be reconsidered. It also makes the translation system easier to audit when several language teams work on the same corpus.

A changed-context transfer exercise

A training organization has an English STIX threat-actor object with a list of three goals and a Japanese local-language view. The first two goals have reviewed translations; the third is not yet reviewed. At the same time, the English source is revised to remove an earlier attribution sentence from its description. A developer proposes to export a two-element Japanese goals list, append the old Japanese description, and set the translation’s source-modified timestamp to the new source time. Determine whether the output can be approved and describe the correct repair path.

The answer is no. The goals list must retain positional correspondence with the source, including a placeholder for the untranslated third element. The old Japanese description needs review against the revised source, especially because an attribution claim has been removed. The developer must not update object_modified merely to suppress a mismatch. The system should record which source version the existing language content actually describes, then create an appropriately reviewed updated translation. It must also preserve object identities, relationships, patterns and markings throughout the operation.

A correct release test resolves the referenced source object, compares list lengths, inspects placeholder interpolation and verifies that the translated description does not resurrect withdrawn attribution. It checks any source sharing restrictions and displays the target output in the intended security viewer. Only after both reference checks and language review pass should the updated translation be treated as current. The transfer principle is not specific to Japanese or threat actors: language content follows the source’s semantics and version, never the convenience of a translation export routine.

Release checklist for a multilingual intelligence feed

Confirm the source object’s identity, version and relevant graph context; approve only translatable property paths; preserve identifiers, timestamps, relationships, patterns, evidence and markings. Validate language tags, object references, nested shapes and exact list alignment. Where object_modified is supplied, ensure it matches the source version being translated. Keep the original available under the same access controls, and document whether the target is publisher-produced or third-party reviewed. No stage should claim that a translation is official merely because it shares the source object’s vocabulary.

Review meanings that affect operational judgment: actor attribution, level of confidence, timing, observed versus inferred behavior, negation, constraints and qualifiers. Test one normal object, one revised object, one partially translated list and one restricted-marking example. Check fallback behavior in the actual consumer. If a field is unsupported by the display tool, do not quietly drop it; document the limitation and determine whether the audience can still make a safe decision from the remaining content.

Save the source revision, language-content revision, review sign-off, schema validation outcome and distribution restrictions. A failed schema check returns to engineering; a mistaken evidence claim returns to the intelligence reviewer and translator; an access-control failure returns to security operations. Separating these owners shortens debugging because the team can name the nature of the defect. Successful STIX translation is not a fashionable dashboard label. It is a controlled alternate reading of an existing, traceable intelligence assertion.

What STIX localization cannot guarantee

The presence of a Language Content object does not certify a translator’s competence, the truth of an intelligence report or the completeness of a threat investigation. Nor does it promise that every consumer supports every language, nested translation property or fallback behavior equally well. Application testing remains necessary. A source can itself contain mistaken attribution or obsolete conclusions, and translation should not disguise those problems. It is reasonable to provide a link to the authoritative wording and clearly state the limitations of a target-language view.

Machine translation may accelerate drafting of benign explanatory strings, but sensitive threat intelligence requires handling controls and domain review. Do not upload restricted source content to uncontrolled translation services, and do not use automatic phrasing to invent detection logic. When the needed context is unavailable, flag the sentence as unresolved rather than guessing. This restraint is a feature of a reliable multilingual security workflow. It protects analysts from confidently stated fabrications that can be more dangerous than a plainly marked missing translation.

Summary: translate the reading, preserve the intelligence

STIX 2.1 Language Content separates human-language alternatives from the referenced structured threat object. Reliable translation begins with source identification and versioning, protects patterns and relationships, uses valid language tags and field paths, preserves list positions, applies markings and checks real displayed meaning. The language-content mechanism gives teams a principled place for translated descriptions, but only careful implementation and review can ensure that those descriptions represent the same intelligence claims.

For a training audience, this approach teaches students why language and evidence are different layers. For a multilingual intelligence-sharing team, it permits readers to understand the same graph across languages without inventing new actors or silently revising claims. Speed comes from explicit boundaries and reusable checks. The result is a translated explanation that helps people make sense of the information, not a changed detection artifact hiding beneath smoother prose.

Frequently asked questions

1. What is the purpose of a STIX 2.1 language-content object?

It represents alternative language content for fields on an existing STIX object, linked using object_ref and optional source-version information.

2. Can I create a second campaign object just to hold another language?

That risks creating an independent intelligence identity. Use the language-content mechanism for a translation of the existing source where appropriate.

3. Is object_modified mandatory?

The specification lists it as optional, but if supplied it must match the source object’s modified timestamp. It is useful for version-specific text.

4. Can I translate indicator pattern syntax?

No. Keep machine patterns and observable contracts unchanged. Translate explanatory prose about their meaning, not the expressions evaluated by software.

5. What if a list has only one translated entry out of three?

Preserve the three positions and use empty-string placeholders for untranslated items in accordance with the STIX Language Content rules.

6. Does a valid JSON parser prove a language-content object is valid?

No. Validate STIX structure, source references and applicable semantic rules separately. A JSON object can parse while referring to the wrong property or source.

7. Do sharing restrictions still apply to translated content?

Yes. Localizing intelligence does not override markings or distribution agreements. Apply access controls before extraction and publication.

8. Can machine translation be used for draft descriptions?

It can assist within an authorized controlled environment, but analysts and language reviewers must check attribution, confidence, negation and technical claims.

9. What happens when the original STIX object is revised?

Compare the new source with the translation’s approved revision and re-review affected fields. Do not merely relabel stale wording as current.

10. How should a viewer handle missing translations?

Use a documented fallback policy, preserving source access and markings. Some list elements can be interpolated according to the spec, but editorial fitness remains a separate decision.

Authoritative sources