Skip to main content
Hyperlocalise Platform brings multilingual content into one workspace. Native projects accept application resource files, documents, images, video, and Office files, but translation and editing differ by format. Upload support alone does not mean a file supports automatic translation or segment editing.

​
Native project file support

The table describes the native source-upload and file workflow. Connected TMS projects follow the provider’s capabilities. Translation workflows require an enabled provider and the relevant workspace access. A listed extension still needs valid content for its parser or viewer.

​
Excel workbooks

Native projects split each .xlsx upload into segments, using the same rules as the CLI Excel guide:
  • A sheet whose first row has a source-locale column, such as English or en-US, is a string table. Each row is one segment, keyed by its Key, ID, or Context column. Comment columns become segment context, and Length limit columns become maximum lengths.
  • Any other visible sheet is a free-form document. Each text cell is one segment keyed by its address, such as Pricing!B3.
Formulas, numbers, cells without letters, and hidden sheets are not segments. Translate and review the segments in Comfortable, Side by side, or Multilingual view. File view lists the segments by sheet next to a preview of the target workbook generated from those translations; see Edit Office files in File view. Download translations returns a copy of the source workbook with ready translations in the target locale’s column, or in place for free-form sheets. Untranslated rows stay empty, and cells for other locales keep their existing text. When the file’s Import filters set a source column and the first row does not name the source language there, the sheet has no column per language: each ready translation replaces the text in the source column, and other rows keep their source text. Translations already in the workbook are not imported on upload; use Import translations with the filled workbook to load them. Legacy .xls workbooks are read with the same rules. Their translated download is an .xlsx workbook, so strings.xls downloads as strings-fr.xlsx.

​
Word and PowerPoint files

Native projects split .docx and .pptx uploads into one segment per paragraph:
  • Word segments come from the document body, then headers, footers, footnotes, and endnotes. Tracked deletions are left out and tracked insertions are read as text, so the translated document has its tracked changes accepted.
  • PowerPoint segments come from slide text boxes and table cells, in slide order. Speaker notes, charts, and SmartArt are not translated.
  • Each segment’s context names its slide and shape, or its Word part and paragraph style.
A paragraph’s main formatting is kept automatically. Text in other formatting, links, and objects such as images, fields, and footnote marks appear as tags like OX#0. Keep every tag in the translation; QA fails a segment that drops or adds one. Download translations returns a copy of the source file with ready translations in place. Untranslated paragraphs keep their source text.

​
PDF documents

Native projects split each .pdf upload into one segment per text block on each page. Keys look like page-1#1 (page 1, block 1). Context reads Page 1, block 1. Scanned PDFs without a selectable text layer cannot be ingested. Translate and review segments in Comfortable or Side by side view. File view shows a canvas preview of the source PDF pages next to the block segments, so reviewers can see each block in its page context. Download translations returns a copy of the source PDF with ready translations written into the text blocks. Blocks that cannot fit after wrapping may still be written with a best-effort layout; overflow keys are listed in the download response when present (X-Hyperlocalise-Overflow-Keys on project and public downloads; overflowKeys on MCP download_translations). PDF export supports Latin, Chinese, Japanese, Korean, Vietnamese, Thai, and Lao targets. A translated block keeps the source font when that font contains the needed glyphs. Other blocks are redrawn with an embedded font, so expect a larger file. Scripts that need complex shaping (Arabic, Hebrew, Indic, Khmer, Myanmar) return pdf_script_unsupported, as does any text no bundled font covers. Google Drive imports .pdf files and pushes translated PDFs back to Drive. Scanned PDFs without selectable text fail ingest. For CLI behavior, see the PDF format guide.

​
Edit Office files in File view

File view shows a field for every segment, grouped by slide, part, or sheet, next to a preview of the generated target file. Edit the fields, then select Save drafts. Each changed field is saved as a draft on its segment after QA runs, and the preview reloads. A field blocked by QA stays marked so you can fix it. Markdown and HTML files with segments save the whole edited file. Changed paragraphs are then saved as drafts on their segments. Added or removed paragraphs, and changed paragraphs that were split into sentences, keep the change only in the file; Platform lists them so you can edit those segments directly. Office files uploaded before segment support are split into segments the first time you open them.

​
Choose a format guide

For a complete Platform workflow, start with one of these tutorials: Native source upload accepts the same catalog extensions as the CLI file-format guides. Upload strings.xml for Android string resources; other .xml files use the generic XML parser. .pot templates use the same gettext parser as .po: an empty msgstr is read from msgid. Native .ts uploads are Qt Linguist catalogs, not TypeScript locale modules. For local translation, use the all-in-one Hyperlocalise CLI.

​
Upload, translate, review, and export

  1. Create a project and choose source and target locales.
  2. Upload your files. The native upload screen accepts up to 10 files per batch.
  3. Start translation.
  4. Review the result in the view available for that file family.
  5. Download translated files and check them in the consuming application.
Uploading alone does not start translation unless you configure a matching source-upload automation.

​
Is a queue export the same as a translated file?

No. A Content Editor queue export contains filtered segments as CSV, TMX, XLF/XLIFF, or XLSX, up to 5,000 matching segments. It is useful for review and handoff. On a native project you can re-import that bilingual file from the Content Editor after you fix tags or wording. Use the project’s Download translations action for complete target files. Document, image, and video file views work with stored files rather than a segment queue. Office downloads are generated from segment translations.

​
Does Platform support every CLI or TMS file format?

Native uploads now accept the same catalog extensions as the CLI, plus images, video, and Office files. Local CLI parsing, native Platform uploads, and provider imports remain separate contracts: a listed extension still needs valid content, and connected TMS projects follow the provider’s import rules. Supporting an export format does not imply a matching source-upload format. If an accepted file cannot open, check upload troubleshooting.