Document processing method and device, electronic equipment and computer readable storage medium

Abstract

An embodiment of the present disclosure provides a document processing method, comprising: obtaining a source document; parsing the source document to extract text content and style information, and mapping into a unified intermediate representation, the unified intermediate representation comprising text content nodes carrying text and style information; the style information in the unified intermediate representation is stored in the form of style attribute data in the text content nodes; extracting the text in the text content nodes from the unified intermediate representation, determining a translation context according to the structural semantic information of each text content node in the unified intermediate representation; performing translation processing on the text carrying the translation context to obtain corresponding target language translation; backfilling the target language translation into the corresponding text content nodes, wherein the structure and style information of the unified intermediate representation remain unchanged except the text value of the text content nodes; according to the style information in the unified intermediate representation, the target language translation and the style information are recombined into a target format document.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to document processing methods, apparatus, electronic devices, and computer-readable storage media. Background Technology

[0002] In related technologies, cross-language processing of multi-format documents typically relies on dedicated parsing pipelines for each document format. Due to significant differences in the underlying data structures of portable document formats, office document formats, and web page formats, functional modules between these pipelines are difficult to share. When expanding the system, it is often necessary to repeatedly develop parsing and rendering components, resulting in low code reusability and high maintenance costs in the system architecture. Furthermore, in processing the content to be translated, related technologies usually extract and process textual semantic information and layout style information separately, requiring additional matching operations to reconstruct the original layout after translation, significantly increasing the data processing load. Simultaneously, the differentiated preprocessing required for different input formats further exacerbates the server's computational pressure, limiting overall processing efficiency. Summary of the Invention

[0003] This disclosure provides a document processing method, apparatus, electronic device, and computer-readable storage medium to at least partially solve the aforementioned problems existing in the related art.

[0004] According to one aspect of this disclosure, a document processing method is provided, the method comprising: obtaining a source document; parsing the source document, extracting text content and style information, and mapping them to a unified intermediate representation, the unified intermediate representation including text content nodes carrying text and style information; the style information in the unified intermediate representation being embedded in the text content nodes in the form of style attribute data; extracting text from the text content nodes in the unified intermediate representation, and determining the translation context based on the structural semantic information of each text content node in the unified intermediate representation; performing translation processing on the text carrying the translation context to obtain the corresponding target language translation; backfilling the target language translation into the corresponding text content nodes, wherein, except for the text value of the text content nodes, the structure and style information of the unified intermediate representation remain unchanged; and recombining the target language translation and style information into a target format document based on the style information in the unified intermediate representation.

[0005] According to one aspect of this disclosure, a document processing apparatus is provided, comprising: a document acquisition module for acquiring a source document; a parsing and mapping module for parsing the source document, extracting text content and style information, and mapping them to a unified intermediate representation, wherein the unified intermediate representation includes text content nodes carrying text and style information; a storage module for embedding and storing the style information in the unified intermediate representation as style attribute data within the text content nodes; a context determination module for extracting text from the text content nodes in the unified intermediate representation and determining the translation context based on the structural semantic information of each text content node in the unified intermediate representation; a translation processing module for performing translation processing on the text carrying the translation context to obtain the corresponding target language translation; a translation backfilling module for backfilling the target language translation into the corresponding text content nodes, wherein, except for the text values ​​of the text content nodes, the structure and style information of the unified intermediate representation remain unchanged; and a document synthesis module for resynthesizing the target language translation and style information into a target format document based on the style information in the unified intermediate representation.

[0006] According to one aspect of this disclosure, an electronic device is provided, comprising: a memory storing computer-executable instructions executable by a processor; and a processor for executing the computer-executable instructions to implement any of the above methods.

[0007] According to one aspect of this disclosure, a computer-readable storage medium is provided that stores a computer program, which, when executed by a processor, implements any of the above methods.

[0008] One embodiment of this disclosure provides a document processing method, including: acquiring a source document; parsing the source document, extracting text content and style information, and mapping them to a unified intermediate representation, wherein the unified intermediate representation includes text content nodes carrying text and style information; the style information in the unified intermediate representation is embedded in the text content nodes in the form of style attribute data; extracting text from the text content nodes in the unified intermediate representation, and determining the translation context based on the structural semantic information of each text content node in the unified intermediate representation; performing translation processing on the text carrying the translation context to obtain the corresponding target language translation; backfilling the target language translation into the corresponding text content nodes, wherein, except for the text values ​​of the text content nodes, the structure and style information of the unified intermediate representation remain unchanged; and recombining the target language translation and style information into a target format document based on the style information in the unified intermediate representation. Thus, by embedding the unified intermediate representation and style attribute data, it helps reduce the data processing pressure in the independent parsing and translation process of multi-format documents, reduces the computational overhead of style reconstruction in the rendering stage, and improves the accuracy of translation context construction and the consistency of style restoration. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 A schematic diagram of a system architecture is shown in one exemplary embodiment of this disclosure. Figure 2 This diagram illustrates a document processing method flowchart according to one exemplary embodiment of the present disclosure; Figure 3 This diagram illustrates the structure of a document processing apparatus according to one exemplary embodiment of the present disclosure. Figure 4 A schematic diagram of the structure of an electronic device is shown in one exemplary embodiment of the present disclosure. Detailed Implementation

[0011] To enable those skilled in the art to better understand the present disclosure, the technical solutions of the present disclosure will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present disclosure, and not all embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present disclosure.

[0012] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0013] The accompanying drawings are schematic illustrations of this disclosure and are not necessarily drawn to scale. Some block diagrams shown in the drawings may be functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in hardware modules or integrated circuits, or in networks, processors, or microcontrollers. Implementations can be carried out in various forms and should not be construed as limited to the examples set forth herein. The features, structures, or characteristics described in this disclosure can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough description of embodiments of this disclosure. However, those skilled in the art will recognize that one or more specific details may be omitted when implementing the technical solutions of this disclosure, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

[0014] Figure 1 A system architecture diagram of the operating environment of this exemplary embodiment is shown. This system architecture may include a terminal device 110 and a server 120. The terminal device 110 may be a mobile phone, tablet computer, personal computer, smart wearable device, game console, etc., and has a display function capable of displaying a graphical user interface, which may include the operating system interface or the application interface. An application, such as a game program, is installed on the terminal device 110. The server 120 generally refers to the backend system providing application services in this exemplary embodiment; it may be a single server or a cluster of multiple servers. For example, a game server program is deployed on the server 120 to perform server-side game data processing. The terminal device 110 and the server 120 can be connected via a wired or wireless communication link for data transmission. The method in one exemplary embodiment of this disclosure can be executed by any one or more of the terminal device 110 and the server 120.

[0015] In one implementation, the above method can be implemented and executed based on a cloud interaction system. The cloud interaction system can be the system architecture described above. Various cloud applications, such as cloud gaming, can run under the cloud interaction system. Taking cloud gaming as an example, cloud gaming can be a game mode based on cloud computing. In the cloud gaming operation mode, the game program's execution entity and the game screen presentation entity are separated. The storage and execution of the game's control and interaction methods are completed on the cloud gaming server (such as the aforementioned server 120). The cloud gaming client (such as the aforementioned terminal device 110) is responsible for receiving and sending data and presenting the game screen. For example, the cloud gaming client can be a display device with data transmission capabilities located close to the user, such as a mobile terminal, television, computer, or PDA; while the cloud gaming server in the cloud performs information processing. When playing the game, the user operates the cloud gaming client to send operation commands to the cloud gaming server. The cloud gaming server runs the game according to the operation commands, encodes and compresses the game screen and other data, returns it to the cloud gaming client via the network, and finally, the cloud gaming client decodes and outputs the game screen.

[0016] In one implementation, the method described above can be implemented by the terminal device 110 alone. For example, without deploying the server 120, the terminal device 110 can run the application in a standalone environment to implement the game function and execute the method described above.

[0017] A document processing method according to one embodiment of this disclosure, such as Figure 2 As shown, the method may include: Step S210: Obtain the source document; Step S220: Parse the source document, extract the text content and style information, and map them into a unified intermediate representation. The unified intermediate representation includes the text content nodes that carry the text and the style information. Step S230: Unify the style information in the intermediate representation and store it in the form of style attribute data embedded in the text content node; Step S240: Extract the text from the text content nodes in the unified intermediate representation, and determine the translation context based on the structural semantic information of each text content node in the unified intermediate representation; Step S250: Perform translation processing on the text carrying the translation context to obtain the corresponding target language translation; Step S260: Backfill the target language translation into the corresponding text content node, wherein, except for the text value of the text content node, the structure and style information of the unified intermediate representation remain unchanged; Step S270: Based on the style information in the unified intermediate representation, the target language translation and style information are recombined into a target format document.

[0018] According to one embodiment of this disclosure, by unifying the intermediate representation and the embedded storage of style attribute data, it helps to reduce the data processing pressure in the independent parsing and translation process of multi-format documents, reduce the computational overhead of style reconstruction in the rendering stage, and improve the accuracy of translation context construction and the consistency of style restoration.

[0019] The embodiments of this disclosure will now be further described.

[0020] In step S210, the source document is obtained.

[0021] For example, the system can receive user-submitted Portable Document Format (PDF), Office Document Format (DOCX), Hypertext Markup Language (HTML) web pages, Presentation Document Format (PPTX), or Spreadsheet Format (XLSX) files as source documents to be translated via a file upload interface. During the acquisition process, the system first identifies the file extension or file header magic number of the source document to preliminarily determine its format type, and then temporarily stores the raw binary data stream of the file in a memory buffer, awaiting the subsequent parsing stage. It should be noted that the source document can also be obtained by pulling from a cloud storage service or reading from a local disk path; this disclosure is not limited to these methods.

[0022] Optionally, the source document includes electronic files in various formats carrying the text and image information to be translated, serving as raw input to the translation processing pipeline. Optionally, the source document can be a Portable Document Format (PDF) file, a Doppler Office Format (DOCX) webpage, an HTML webpage, a Presentation Document Format (PPTX) slide collection, a Spreadsheet Format (XLSX) workbook, an EPUB (Electronic Publication) ebook, or Markdown (a lightweight markup language). Although these file types employ different storage mechanisms at the underlying level, such as layout coordinate instructions, nested compressed structures, tag tree hierarchies, or plain text streams, they all simultaneously contain the main text to be translated and its corresponding style description data. Considering the significant differences in decoding methods for structural metadata of different formats, the acquisition stage must maintain the integrity of the original binary or text data of the source document to avoid premature transcoding or structural flattening that could lead to inaccurate extraction of style attributes later. The source document can be either a file stream submitted by the user through the front-end upload control, or a data stream pulled in batches from a distributed storage system or a remote server. If a network transmission interruption or file verification failure occurs, a retransmission mechanism can be triggered or an error message can be returned. This disclosure does not limit the scope of the embodiments.

[0023] In step S220, the source document is parsed, text content and style information are extracted, and mapped to a unified intermediate representation. The unified intermediate representation includes text content nodes carrying the text and style information. In this way, by converting heterogeneous source documents into a unified intermediate representation carrying styles, complete layout information can be preserved while masking underlying format differences, laying a structural foundation for subsequent high-fidelity translation processing and cross-format rendering.

[0024] Optionally, text content is a sequence of characters in the source document that carries readable semantics and needs to be translated. Text content can be extracted from text nodes in HTML, text elements in Word documents, text blocks in PDFs, shared string entries in Excel, or text nodes in presentation documents. Examples include paragraph text within paragraph tags in HTML documents, character data of body paragraphs in Word documents, and character sequences of text blocks arranged by coordinates in a PDF page. Text content can also include local style embellishments defined using inline tags.

[0025] Optionally, style information is a collection of metadata describing how text is presented in a document, including typography attributes such as font name, font size, color value, line spacing, paragraph spacing, and alignment. Style information is stored in different forms in the source document, such as Cascading Style Sheets (CSS) attributes in HTML, style definition structures in Word documents, and text rendering instructions in PDFs.

[0026] Optionally, a unified intermediate representation is a standardized data structure for cross-format document translation that maps the parsed content of source documents in different formats to a single data model. Independent of any specific document format, a unified intermediate representation contains text content nodes that carry the text, as well as style information describing the presentation style of each text content node. In the intermediate representation, the hierarchical relationship between text content nodes is defined through container nodes. For example, a simple HTML document containing a title and body text can be mapped to a unified intermediate representation containing a title-type text content node and a body-type text content node, both appended with style attribute data extracted from the Cascading Style Sheets (CSS) rules of the source HTML. In another example, a PDF page containing multiple text blocks can be mapped to a unified intermediate representation containing a page container node, which internally contains multiple text block nodes, each carrying coordinate and font style attribute data extracted from the PDF.

[0027] Optionally, a text content node is the smallest translatable data node in the unified intermediate representation that carries the actual text value. It is responsible for storing the character sequence to be translated and, after translation, the corresponding target language translation. A text content node can be a text element in Extensible Markup Language (XML) or a leaf node in a tree structure. In one specific example, the text content node is an XML text element containing the text string "Hello World," along with style attribute data describing the font, size, and color. In another example, the text content node is a JavaScript object representation object, containing a value field storing the text content and a style field storing style attribute data. In yet another example, the text content node is a Python dictionary object, with one key storing the text string and another key storing style attribute data in dictionary form.

[0028] In an optional implementation, the source document is parsed to extract text content and style information, which is then mapped to a unified intermediate representation. This includes: identifying the format type of the source document; extracting text content and style information using a parsing strategy corresponding to the format type; and mapping it to a unified intermediate representation. By identifying the format type and employing the corresponding parsing strategy, adaptive entry processing can be performed on documents of different formats, providing an accurate structured foundation for the generation of the unified intermediate representation and significantly improving multi-format compatibility and processing accuracy.

[0029] For example, when the system receives a source document to be translated, it first performs a format recognition operation. Specifically, if the file header is found to conform to the characteristics of a compressed package and contains a content type definition file and a text processing subdirectory, the source document is determined to be a text processing document format. Then, a parser based on the Open Extensible Markup Language (OPL) standard is called to decompress the document and extract the text nodes and style definitions from the content file. If the file is found to start with a specific layout document feature markup, such as starting with the hexadecimal magic number '25 50 44 46' (i.e., the ASCII character '%PDF'), starting with the '%PDF-1.4' version declaration, or starting with any markup in the '%PDF-' series of version identifiers, it is determined to be a layout document format. Then, the page identifier, geometric coordinates, and reading order identifiers of each text block are extracted to reconstruct the semantic structure. If the file is found to start with a Hypertext Markup Language (HTML) tag, it is determined to be a web page format. Then, a normalization tool is called to process and extract the content nodes and cascading style attributes, ultimately mapping them uniformly to the intermediate layer of the HTML structure.

[0030] Optionally, the format type is used to characterize the file structure specifications followed by the source document, which can be distinguished by the extension, file header features, or internal structure identifiers. Considering the potential for misjudgment with a single verification mechanism during batch document recognition, as a possible implementation, the system can combine multiple auxiliary information for joint judgment. For example, if the input file is a text processing document format with a compressed archive structure containing content type definition files and a text processing folder, the system recognizes it as a text processing streaming document based on the Open Extensible Markup Language (OOM) standard; if the file begins with a specific layout document feature markup, it is recognized as a layout document; if the file contains Hypertext Markup Language (HML) tags or specific text-type marksup, it is recognized as an HML format. It should be noted that the above-mentioned format type judgment logic is only one example. In actual deployment, the system can also combine multi-dimensional verification rules for comprehensive judgment. This disclosure is not intended to limit the recognition methods. Furthermore, for source documents that have been encrypted or obfuscated internally, auxiliary recognition can be performed by detecting the internal directory structure of the compressed archive or the distribution density of markup language tags to ensure that the parser accurately matches the actual file structure.

[0031] Optionally, the parsing strategy aims to perform differentiated content extraction and style extraction based on the structural characteristics of the format type, and map the results to a unified document object model. Optionally, the above parsing strategy refers to differentiated content extraction rules and mapping logic designed for different underlying storage mechanisms. As a possible implementation, for documents stored based on markup language structures, the parsing strategy may include traversing the document object tree to identify content nodes carrying text, and simultaneously extracting inline or cascading style attribute data; for documents stored based on layout structures, the parsing strategy may include extracting page identifiers, the geometric coordinates of text blocks on the page, and reading order identifiers, and reorganizing discrete text blocks into a semantic structure with reading order based on physical layout information before mapping. Furthermore, for spreadsheet formats using shared string structures, the parsing strategy may focus on reading string entries and their associated styles in the shared string table, thereby avoiding redundant operations caused by directly traversing worksheet cells. It should be understood that the above storage mechanisms are merely examples, and the scope of the parsing strategy can be extended to other types such as presentation documents, ebooks, or lightweight markup language documents. This disclosure is not intended to limit the applicable file types.

[0032] Optionally, to avoid processing fragmentation due to format diversity, the above parsing strategy can be implemented using either a dedicated format parser or a plug-in parsing framework. In one specific implementation, the system can pre-configure a parser registry, binding each format type to its corresponding parser implementation class. After the format recognition module outputs a judgment result, the translation platform dynamically loads the target parser instance from the registry based on the result and passes it into the source document data stream. It should be understood that the selection of the parsing strategy is not only related to the format type but also to the required granularity of the information to be extracted. If the subsequent translation scenario requires the retention of more refined typesetting information, the corresponding parsing strategy can be configured to extract multi-dimensional style attributes such as font name, font size, color encoding, and paragraph spacing, and append these attributes as embedded data to the corresponding nodes of the unified intermediate representation. Furthermore, the parsing strategy can also be loaded via static linking or remote service calls; this disclosure does not limit this method.

[0033] In an optional implementation, the source document is a document format stored based on a markup language structure. Text content and style information are extracted using a parsing strategy corresponding to the format type and mapped to a unified intermediate representation. This includes: reading content nodes in the markup language structure to extract text content, and extracting style attribute data from the markup language structure to obtain style information; and mapping the extracted text content and style information to the unified intermediate representation. In this way, by directly reading the embedded content nodes and style attribute data in the markup language document, the complex physical coordinate reconstruction process of the layout document is avoided, which not only improves parsing efficiency but also ensures the complete preservation of structured semantic information during the mapping process.

[0034] For example, when the source document is in Hypertext Markup Language (HTML) webpage format, the system calls the corresponding markup language parser and uses markup language normalization tools to organize the loose original webpage structure into a well-formatted Extensible Hypertext Markup Language (EXTL). This EXTL naturally conforms to the EXTL syntax specification. Subsequently, the system directly reads the content nodes in the markup language structure to extract the text content of paragraphs, and at the same time extracts the style attribute data embedded in the tags. The extracted text content and style attribute data are then mapped to a unified intermediate representation, thereby providing a standardized input with a clear structure and complete style for the subsequent translation stage.

[0035] Optionally, document formats based on markup language structure storage can include Hypertext Markup Language (HTML) web pages and their normalized Extensible Hypertext Markup Language (XHTML) documents. Considering that such documents naturally employ a tree-like tag structure to organize hierarchical content nodes, with text and style information embedded within tags and attributes at each level, the system does not need to perform complex calculations such as physical coordinate extraction and reading order restoration required for formatted documents during the parsing phase. Instead, it can directly call the Document Object Model (DOM) interface to read and map the original document structure. For example, for loosely structured original HTML documents, tools such as HTML Tidy can be used to format them into well-formed XHTML. This XHTML naturally conforms to the Extensible Markup Language (XML) syntax specification, thus requiring only a small amount of tag mapping to be integrated into the DOM defined in this disclosure. Furthermore, the parsing timing can be set to trigger immediately after batch import, or the corresponding parser can be dynamically invoked after detecting that the user has specified the format. It should be noted that the above description of markup language types is only an example, and this disclosure is not intended to limit the scope of document formats. In practical applications, it can also cover other electronic publishing formats derived from XML.

[0036] Optionally, besides directly traversing the markup language structure once using the Document Object Model (DOM) interface, in scenarios involving extremely large markup language documents or requiring batch conversion across formats, the above parsing strategy can also employ a streaming approach. This involves extracting content nodes and style attribute data sequentially according to the order in which document tags appear, and mapping them in real time to segments with a unified intermediate representation. The advantage of this approach is that the system does not need to load the entire document into memory to build a complete tree structure during parsing, thus significantly reducing the peak memory usage during large-scale document processing. Furthermore, this streaming processing architecture can form an efficient data pipeline with the subsequent translation stage; that is, after the parser completes the extraction and intermediate layer mapping of a text block, it can immediately send that text block to the translation engine for asynchronous processing without waiting for the entire document to be parsed. It should be understood that the streaming parsing method and the tree model parsing method can be dynamically selected based on the document size, server memory resources, and real-time requirements; this embodiment does not limit this selection.

[0037] Optionally, content nodes refer to various hierarchical tag elements used to encapsulate actual translatable text within the markup language structure. Considering that markup language documents organize information using a tree structure, as a possible implementation, the aforementioned content nodes may include paragraph tags in the top-level structure, heading tags at various levels used to define chapter levels, and inline text containers such as emphasis tags and hyperlink tags embedded within paragraphs. For example, when the system traverses the document object model tree of a hypertext markup language document, it can directly locate the body text wrapped by paragraph tags, the chapter titles wrapped by first to sixth-level heading tags, and local text fragments within inline content containers or link tags, and extract the plain text content from these nodes to construct a list of text to be translated. It should be noted that the above list of tag types is not intended to exhaustively cover the scope of content nodes. In actual implementation, it can also cover text data contained in list item tags, table cell tags, and custom tags, as long as the node carries text values ​​to be translated, it can be included in the extraction scope.

[0038] Optionally, style attribute data refers to a set of data recorded in a markup language document to control the visual appearance and layout of text. As one possible implementation, this style attribute data can be directly recorded inline in the attribute fields of content nodes. For example, it can specify text color through font color attributes, text size through font size attributes, or the text layout on the page through alignment attributes. Alternatively, the style attribute data can also be a unified set of style rules defined within a set of style tag blocks within the document. In this case, content nodes can establish a reference association with the corresponding style rules through category attributes or identifier attributes. Considering that the rendered translated document will lose its original layout features if the style attribute data is lost, one objective of this embodiment is to ensure that the translated target language text can reuse the original visual style by fully extracting and embedding this style attribute data during the parsing stage. This also provides sufficient layout basis for subsequent reverse rendering of multi-format target documents using a unified intermediate representation. It should be noted that the above description of the style recording format is only an example; in actual implementation, it can also include auxiliary layout information carried in custom data attributes.

[0039] In an optional implementation, the source document is a layout document. Text content and style information are extracted using a parsing strategy corresponding to the format type and mapped to a unified intermediate representation. This includes: restoring text blocks to a semantic structure with reading order based on the physical layout information recorded in the source document, and mapping the semantic structure to the unified intermediate representation. The physical layout information includes: page identifiers, the geometric coordinates of the text blocks on the page, and the reading order identifiers of the text blocks. Thus, by parsing and semantically restoring the physical layout of the layout document, not only can discrete text blocks be restored to a coherent text, but the spatial characteristics of the original layout can also be preserved in the unified intermediate representation, improving the accuracy of subsequent rendering.

[0040] For example, the source document to be processed is a multi-column portable document format (PDF) technical manual, whose underlying structure is simply a collection of coordinate-based text blocks. The system calls the layout document parser to extract the page identifier of each page, the geometric coordinates of each text block on the page, and the reading order identifier generated by the parsing tool. Based on this information, the parser first groups text blocks with similar vertical coordinates and continuous horizontal coordinates on the same page into a single line of text. Then, based on the vertical spacing between lines and the cross-column connection relationship, it restores the scattered text blocks into semantic structures such as paragraphs and headings that follow the natural reading order. Subsequently, the system maps the semantic structure with preserved coordinates to a unified intermediate representation, enabling subsequent stages to obtain the translation context based on semantic coherence and accurately reproduce the layout of the original document during rendering. In another example, the source document to be processed is a single-column PDF contract text containing headers, footers, and sidebar annotations. Based on the vertical spacing abrupt change detection rules in the physical layout information, the system identifies the header and footer text blocks at the top and bottom of the page as auxiliary information and excludes them from the main reading sequence. The text blocks in the main text area in the middle are sorted according to the vertical coordinate and restored to a continuous semantic structure of contract terms, thereby avoiding the incorrect splicing of header information with the main text terms during translation.

[0041] Optionally, a layout document refers to a file format that records visual presentation information with a fixed page layout, and its text content is usually stored discretized based on physical coordinates. Optionally, a layout document can be a portable document format (PDF) file, an e-book document stored in a fixed layout, or a layout image document generated after scanning. The core characteristic of this type of document is that its page content is not structured by logical paragraphs, headings, or other semantic tags, but rather uses the page as a carrier, achieving visual rendering by recording the precise coordinate position of each text block on the page. Because of this, directly extracting its text often only yields a large number of fragmented and disordered text fragments. Considering this objective storage law, this embodiment does not simply output a disordered text stream during the parsing stage, but introduces a physical layout information analysis mechanism to restore the originally fragmented text blocks into a semantic structure with a reading order, thereby providing a data source for subsequent unified intermediate representation that retains both layout characteristics and semantic coherence.

[0042] Optionally, physical layout information is used to record the spatial distribution and page ownership of text blocks in the layout document, serving as a crucial basis for reconstructing the reading order. Optionally, physical layout information includes, but is not limited to, page identifiers, the geometric coordinates of text blocks within the page, and reading order identifiers. Page identifiers distinguish different pages, ensuring that the parsing results of multi-page documents do not interfere with each other. Geometric coordinates are generally established with the top-left corner of the page as the origin, using a two-dimensional coordinate system extending horizontally to the right and vertically downwards to record the x and y coordinates of the text block's starting point. The reading order identifier is automatically generated by the parsing tool based on the text block's coordinate overlap, column segmentation, and area flow analysis, indicating the order in which text blocks are read within the layout. It should be noted that the specific recording format and acquisition method of the above information can be adjusted according to the actual layout parsing engine used; this disclosure is not limited to a specific coordinate description standard. In actual processing, the system can also combine auxiliary parameters such as the width, height, and font size of text blocks to further verify and optimize the inferred reading order results, addressing common issues in complex layouts such as mixed text and image layouts and multi-column wrapping.

[0043] Optionally, a text block is the smallest discrete unit carrying visible characters in a layout document, and its content is independently located and rendered based on physical coordinates. Optionally, within a layout document, a text block is typically represented as an atomic data object composed of a sequence of characters, sharing common positional and style attributes. For example, in Portable Document Format (PDF), a text block can be a single word, phrase, or short sentence located at specific coordinates, with its boundaries automatically defined by the parser based on positional movement instructions in the operator sequence. Considering the differences in how different layout documents are generated, the granularity of text blocks is not fixed: in one case, a complete sentence may be split into multiple text blocks separated by spaces; in another case, continuous text belonging to the same paragraph may be further subdivided due to subtle differences in font or color. Therefore, this embodiment, after extracting text blocks, does not directly map them to a unified intermediate representation, but first aggregates and reorganizes them based on geometric coordinates and reading order identifiers, thereby transforming discrete units into semantic structures that conform to language logic.

[0044] Optionally, the semantic structure of the reading order refers to the continuous text organization form formed after the text blocks are reorganized, possessing hierarchical semantics and conforming to the reading order. Optionally, the semantic structure of the reading order can include text organization forms with clear semantic roles, such as headings, paragraphs, list items, and table cells. Considering that text blocks in layout documents are often arranged according to the execution order of rendering instructions rather than the reading order, directly translating according to the extraction order will lead to fragmented text and inverted semantics. As a possible implementation, the system first performs column detection based on the vertical distribution density of the geometric coordinates of the text blocks, and treats areas with overlapping vertical coordinates as the same column; then, within the same column, it sorts them according to the horizontal coordinate from left to right, and between different columns, it sorts them according to the reading flow from top to bottom or according to specific cultural habits. To avoid paragraphs being incorrectly segmented due to cross-page sentence breaks or interference from headers and footers, the system can also detect abrupt changes in spacing between text blocks: if the vertical spacing between adjacent text blocks is significantly greater than the average line spacing within the same paragraph, it is considered a paragraph boundary. Through the above processing, the originally isolated text blocks are reorganized into a reading sequence with semantic hierarchy, enabling the translation engine to obtain coherent semantic information based on context.

[0045] Optionally, the mapping result of the semantic structure and the unified intermediate representation adopt a loosely coupled node association method. For example, a text sequence identified as a first-level heading corresponds to a text content node containing heading level attributes in the unified intermediate representation, while a regular paragraph corresponds to a text content node containing paragraph attributes. Furthermore, in order to preserve the layout restoration capability during the rendering stage, in addition to carrying the aggregated complete text string, the semantic structure node can also embed and store the original geometric coordinate extreme values ​​of its constituent text blocks, that is, the maximum and minimum horizontal and vertical coordinates of the area covered by the semantic structure. In other words, even if multiple text blocks are logically merged into a paragraph, the original position information is still preserved in the form of style attribute data. If a text block simultaneously crosses two semantic role regions, it can be assigned to the dominant region according to the area proportion principle, or it can be split into two independent semantic structure fragments for separate processing. This disclosure does not limit this.

[0046] In an optional implementation, the source document is in spreadsheet format, and the spreadsheet format uses a shared string structure to store text content. The shared string structure includes a shared string table, where each string entry is referenced by a cell in the worksheet via an index value. Parsing the source document, extracting text content and style information, and mapping them to a unified intermediate representation includes: reading each string entry in the shared string table, extracting style attribute data associated with each string entry in the source document as style information; mapping each string entry to a text content node in the unified intermediate representation, mapping the style information to style attribute data embedded in the corresponding text content node, and storing the index value in the unified intermediate representation; and recombining the target language translation and style information into a target format document based on the style information in the unified intermediate representation, including: updating the translated string entries in the shared string table of the source document according to the index value, so that all cells referencing the same string entry synchronously obtain the target language translation; wherein, the index reference relationship between cells in the worksheet and string entries in the shared string table remains unchanged throughout the translation process. In this way, by utilizing the shared string mechanism of spreadsheet format, each string entry in the shared string table is mapped to an independent text content node in a unified intermediate representation. During the translation backfilling stage, the entry values ​​in the shared string table are updated to achieve synchronous updates throughout the translation process, avoiding the inefficiency of backfilling each cell individually. At the same time, it ensures that all cells referencing the same original text automatically maintain consistent translations after translation, significantly improving the translation efficiency and consistency assurance of spreadsheet documents.

[0047] For example, when processing an XLSX format spreadsheet source document, the system first unzips the document package and locates the sharedStrings.xml file, reading the sequentially arranged string entries and their index values. Subsequently, the system maps each string entry to a text content node in the unified intermediate representation and appends the style attribute data of the entry in the original worksheet as embedded style information to the corresponding cell. After translation, the system directly replaces the original string entries in the shared string table with the target language translation based on the index values ​​recorded in the unified intermediate representation. Since each cell in the worksheet references the entry only through the index value, all referenced locations will automatically and synchronously present the updated translation without modifying the cell content one by one, and the index reference relationship between the cell and the shared string table remains unchanged throughout the entire translation process.

[0048] Optionally, a shared string table is used to centrally store all string entries. Worksheet cells reference this table using index values ​​to retrieve the text content. Optionally, the shared string table can be a data structure defined in the sharedStrings.xml file format conforming to the Office Open XML standard, where each string entry corresponds to an independent text fragment that may be referenced by multiple cells in the spreadsheet. Considering that the same text content may appear repeatedly in multiple cells in a spreadsheet document, centrally storing all string entries in a shared string table can significantly compress file size and avoid redundant storage of the same text in the underlying storage. Furthermore, during translation, the system only needs to perform a single traversal and text extraction on the shared string table to obtain all the content to be translated, without having to read thousands of cells in the worksheet one by one. Further, the system synchronously records the index values ​​of each string entry in a unified intermediate representation, enabling the translated target language text to be accurately written back to the original position based on the index value, thereby ensuring that all cells referencing the same index value automatically receive the synchronously updated translation.

[0049] Optionally, besides extracting the entire shared string table into a unified intermediate representation, the system can also extract only string entries containing natural language text, excluding pure numerical values, date codes, or formula calculation results from the translation scope. In other words, during the reading of the shared string table, the textual characteristics of each string entry can be pre-identified, such as whether its string length is much greater than the typical number of digits, whether it contains a continuous character sequence within the natural language character set, or whether it consists only of short numbers and punctuation. If a string entry is determined not to be natural language text, its translation processing can be skipped, and its index value and original text value can be recorded as is in the bypass node of the unified intermediate representation. This avoids the translation engine making invalid calls to content that does not need translation, reduces translation costs, and minimizes the risk of misjudging non-textual content during the rendering stage.

[0050] Optionally, cells are associated with a shared string table based on index values. This association remains unchanged throughout the translation process to ensure that the translation is obtained synchronously at each reference.

[0051] Optionally, the aforementioned index reference relationship is reflected in the integer tag attribute recorded by the worksheet cell node in the underlying spreadsheet file. The value of this attribute corresponds to the sequence number position of a specific string entry in the shared string table. During the parsing phase of the translation process, the system extracts this integer index value as key metadata and embeds it in a unified intermediate representation. After entering the rendering phase, the system locates the original string entry in the shared string table based on this index value and directly replaces it with the target language translation. Since all cell nodes referencing this entry do not undergo any data changes, their index values ​​remain constant throughout the translation process. Therefore, when the spreadsheet file is reassembled, all relevant cells will automatically point to the updated translation entry, achieving the effect of translating in one place and displaying simultaneously in multiple places.

[0052] In an optional implementation, the source document is in presentation document format. Parsing the source document extracts text content and style information, and mapping it to a unified intermediate representation. This includes: reading the source document at the slide level, identifying content nodes, paragraph-level attribute nodes, and text-level attribute nodes carrying text, where paragraph-level attribute nodes define the overall style features of a text block, and text-level attribute nodes define the local style features of a text fragment; mapping the text in the content nodes as text content to text content nodes in the unified intermediate representation, and mapping paragraph-level attribute nodes and text-level attribute nodes to style attribute data embedded in the corresponding text content nodes. In this way, by parsing the presentation document at the slide level and distinguishing between paragraph-level and text-level style attributes, not only is accurate mapping to the unified intermediate representation achieved, but the overall layout and local font styles are also fully preserved, avoiding loss of master formatting or hierarchical confusion after translation.

[0053] For example, when the system receives a presentation document to be translated, it first identifies its format as a presentation document format, and then decompresses and reads the underlying Open XML (Open Extensible Markup Language) structure file slide by slide. For the first slide, the system traverses its tree structure, identifying the content nodes carrying the text, paragraph-level attribute nodes defining the overall alignment and indentation rules of the text block, and text-level attribute nodes defining the specific font color and size of the text segment. Then, the system extracts the text to be translated from the content nodes into text content nodes, and maps the two types of attribute nodes to the style attribute data embedded in the text content nodes, thus completing the conversion of the slide content into a unified intermediate representation. Further, the system performs the same processing on the remaining slides until all the text and style information of the presentation document are seamlessly integrated into the unified intermediate representation system.

[0054] Optionally, the aforementioned presentation document format can be a presentation document file conforming to the Open Extensible Markup Language (Open XML) standard file format, such as a file stored with the presentation document extension. This type of file format is physically stored as a compressed package, where each slide corresponds to an independent structured core file, and the content between slides is isolated from each other at the storage level. Considering the significant non-linear text flow characteristic of presentation documents, their content organization does not rely on physical coordinate arrangement like layout documents, but rather on the logic of the slide sequence and the hierarchical structure of text boxes within the slides. Therefore, as a possible implementation, when processing this type of format, the system reads the document at the smallest processing granularity, which on the one hand avoids translation context confusion caused by disordered text splicing across slides, and on the other hand facilitates decoupling and mapping from global style definitions such as master slides and layouts. It should be noted that the above description regarding the presentation document format suffix is ​​only one example, and this disclosure is not intended to limit it. In actual implementation, the aforementioned presentation document format can also be other presentation-type files based on similar packaging structures and markup language specifications.

[0055] Optionally, to avoid excessive memory usage or a surge in parsing complexity due to loading the entire presentation document at once, the above-mentioned slide-by-slide reading process can further include: during the loading phase, only the structured core file corresponding to the currently processed slide and its associated layout definition file are decompressed and read, while the structured files of the remaining slides are kept compressed or not read into memory. Furthermore, when identifying the content nodes carrying text, in addition to traversing the slide's own tree nodes, the system can also combine the master slide nodes and layout nodes referenced by the slide to merge the default style attributes defined in the master slide into the style attribute data of the current text content node. That is, if a text fragment does not define a specific font color in the slide's own node, but defines a default color in its inherited master slide layout, then that default color will also be mapped to the corresponding style attribute data, thereby ensuring that the translated and rendered slide maintains a high degree of visual consistency with the original document. It should be understood that in specific implementations, the above master style merging strategy can be selected based on actual layout requirements.

[0056] Optionally, the aforementioned slide granularity defines the smallest unit of reading a presentation document, extracting text and styles based on a single slide. Optionally, this slide granularity means that when processing a presentation document, the system does not parse the entire document as a flat, long text stream all at once, but rather uses each independent slide as the boundary for content extraction and transformation. Considering the inherent structural characteristics of presentation documents, text boxes within the same slide revolve around the same theme, and the semantic relationships between text fragments are relatively close; however, the content jumps between different slides are significant, and forcibly splicing them together can easily cause contextual noise pollution to the translation engine. Therefore, as a possible implementation, during the reading phase, the system first locates the structured core file representing a single slide in the presentation document's compressed package, performs node recognition and text extraction operations only on this file, and after all content nodes within that slide have been processed, it sequentially or in parallel switches to the structured core file of the next slide. Furthermore, the aforementioned processing granularity can also be combined with a multi-threaded scheduling mechanism, allowing multiple independent slides to be parsed simultaneously and mapped to different logical partitions in a unified intermediate representation, thereby significantly reducing the overall preprocessing time for large-scale presentation documents. One objective of this embodiment is that, through the above-mentioned boundary division, the data size of single-step parsing can be reduced on the one hand, and the local purity of the translation context can be ensured on the other hand.

[0057] Optionally, the aforementioned paragraph-level attribute nodes are designed to carry the overall style features of a text block, defining overall layout rules and mapping them to style attributes. Optionally, these paragraph-level attribute nodes can be markup nodes in the underlying Open XML (Open Extensible Markup Language) structure of the presentation document used to define the overall layout of a text paragraph. The overall style features defined by this node apply to a complete text block or paragraph entity, encompassing macro-level layout attributes such as alignment (e.g., left alignment, center alignment, or justification), indentation level, line spacing, and bullet point type. Considering the significant differences in text length between different languages ​​during translation—for example, the number of characters may decrease when translating English into Chinese, while the character length may increase significantly when translating into German—without precise recording of paragraph-level style attributes, the carefully adjusted paragraph alignment and automatic line wrapping rules in the original text are prone to errors during the translation rendering stage. Therefore, as a possible implementation, after identifying the node, the system extracts its overall style features and stores them embedded as style attribute data along with the corresponding text content node. This allows the subsequent rendering stage to reapply completely consistent paragraph-level formatting rules to the translation based on these attributes. It should be noted that the above description of node tagging is only one example; in actual implementation, the paragraph-level attribute node can also be other attribute definition structures with equivalent functionality.

[0058] Optionally, in some specific implementations, the paragraph-level attribute nodes, in addition to recording regular typesetting attributes, may also include a set of default font attributes associated with the text block hierarchy, such as the base font name inherited when the paragraph is not separately set to bold or italic. That is, when the system traverses the text corresponding to a content node, it first reads the paragraph-level attribute node of the paragraph containing that text to establish the overall style baseline of the text block; subsequently, if there is a local overriding definition in the text-level attribute node corresponding to the text fragment (e.g., certain characters are individually set to red), the local definition is then used to overwrite or superimpose the baseline attributes, thereby forming the final complete style description applied to the text fragment. One objective of this embodiment is that by decoupling paragraph-level and text-level styles in a layered manner, on the one hand, the adaptive adjustment behavior of the text box (such as automatic line wrapping and scaling to adapt to the shape) can be uniformly controlled by paragraph-level attributes when the text length changes before and after translation; on the other hand, it also makes the mapping of local special modifications more accurate, avoiding redundant mapping or attribute omissions caused by the system laying all styles at the same level.

[0059] Optionally, the aforementioned text-level attribute nodes are designed to carry local style features of text fragments, used to define local font styles and map them to style attributes. Optionally, the aforementioned text-level attribute nodes can be attribute nodes in the underlying markup structure of the presentation document used to modify the local appearance of text fragments. The local style features defined by this node act on a continuous text fragment within the same paragraph, accurately describing the fragment's font name, font size, font color (including theme color and custom color values), bolding, italic status, and underline type, among other micro-visual attributes. Considering that in actual presentation documents, multiple font styles may be mixed within the same text box—for example, a keyword in the title may be highlighted in red and bold, while the rest of the text remains in a regular black style—if the system only records styles uniformly on a paragraph-by-paragraph basis, this type of local modification information will be completely lost during the conversion process. Therefore, as a possible implementation, when performing mapping, the system binds the local style features extracted from the aforementioned text-level attribute nodes one-to-one with the corresponding text fragments, and embeds them as style attribute data in the corresponding text content node of the unified intermediate representation. In this way, even if the length of the translated text changes during the subsequent target format rendering stage, the system can still apply precise appearance modifications to specific text fragments based on these local style attributes, ensuring that the translated presentation document remains consistent with the original document in terms of font hierarchy and visual emphasis.

[0060] Optionally, in another possible implementation, when processing text-level attribute nodes, the system can also identify and record the hyperlink addresses, language identifiers, or special effects attributes (such as shadows or glow effects) referenced by the node. That is, in addition to basic font style information, the aforementioned text-level attribute nodes can also contain additional interactive or special effects metadata, which can indicate the non-plain text function of the text fragment in the slide. To avoid broken links or lost effects after translation due to ignoring these additional attributes, the system can extract and encapsulate all attribute data from the text-level attribute node into style attribute data while mapping the text content to the text content node. Furthermore, during the rendering stage, based on the records in the style attribute data, when generating the corresponding node in the target format document, the system not only restores the font appearance of the text fragment but also reconstructs hyperlinks or visual effects based on the additional interactive or special effects metadata. It should be noted that the above description of hyperlinks and effects is only one example, and this disclosure is not intended to limit the scope of text-level attribute nodes. In actual implementation, the node can also map other style or functional attributes with local scope.

[0061] In step S230, the style information in the unified intermediate representation is embedded and stored within the text content nodes as style attribute data. This embedding of style information as attribute data within the text content nodes not only achieves atomic-level binding between text and style to prevent style loss or misalignment during translation, but also provides a high-fidelity foundation for rendering, significantly improving the consistency of layout after translation of multi-format documents.

[0062] In one implementation, the unified intermediate representation is stored in Extensible Markup Language (XML) format, where text content nodes are defined as element nodes, and style information is directly appended to these element nodes as attribute key-value pairs. For example, a text content node in its original form contains the element name "Text Node" and embeds the following attributes: font value is "SimSun", font size value is "12pt", and color value is "#000000". Its internal text value is the example text. When the text in this node is translated into the target language, the internal text value is updated to the example translation, while the font, font size, and color attributes remain unchanged throughout the translation process. In this way, a tight embedded storage relationship is formed between style information and text content nodes, enabling style inheritance and restoration without the need for external index tables or style mapping files.

[0063] Optionally, embedded storage is used to directly attach style attribute data to text content nodes to maintain an atomic association between text and style during translation.

[0064] Optionally, the embedded storage can be used to write style attribute data representing font, font size, color, spatial position, and paragraph level into the metadata area or tag attribute area of ​​the text content node in the form of key-value pairs, making each text content node a self-describing data unit. Under this storage structure, when the system traverses the unified intermediate representation to perform translation, the style information of each text content node migrates along with the node itself, eliminating the need to query the external style sheet through a global identifier, thereby reducing the complexity and error probability of node parsing. It should be noted that style attribute data is not limited to being directly embedded in the node's first-level attribute; it can also be nested in the node's sub-description structure. The above embedding method is merely an illustrative example; this disclosure does not limit the specific embedding level of style information, as long as the style information is logically bound to the corresponding text content node.

[0065] In an optional implementation, the unified intermediate representation is a hierarchical structured data model. This model includes text content nodes, which carry the text values ​​to be translated. Style information is embedded within these text content nodes as style attribute data. The text content nodes have a hierarchical relationship, defined by a tree-like node structure. Thus, by abstracting the unified intermediate representation into a hierarchical tree structure carrying styles, it not only accurately maps the nested semantic relationships of the original document but also provides natural hierarchical support for the translation context, effectively improving the translation engine's accuracy in understanding structured semantics.

[0066] In one example, the unified intermediate representation described above can be represented as an Extensible Markup Language (XML) data structure that follows the Document Object Model (DOM). In this model, page nodes are arranged sequentially under the root node, each page node has a paragraph node attached to it, and the paragraph node further contains text content nodes that carry specific text values. The style information of each node is directly attached to the corresponding node in the form of attribute data, thus forming a tree structure with hierarchical nesting relationships from the inside out. Furthermore, for a technical white paper containing multi-level headings and body text, the root node in its unified intermediate representation can correspond to the entire document, the first-level child nodes correspond to each chapter, the next-level child nodes map to paragraphs or tables within each chapter, and the text content nodes precisely carry the text fragments within each paragraph, with all style attributes stored embeddedly along with the corresponding nodes.

[0067] Optionally, the unified intermediate representation adopts a hierarchical structured data model, which carries document content and style attributes in a nested form, and supports tree traversal to establish structured relationships between nodes.

[0068] Optionally, the aforementioned hierarchical structured data model can be implemented as an Extensible Markup Language (XML) data structure that follows the Document Object Model. In this model, each text content node is organized into a set of nodes with parent-child and sibling relationships according to the document's logical structure. In this model, parent nodes at the top level can represent logical partitions or page containers, nodes at the middle level can represent text blocks such as paragraphs, headings, and list items, while text content nodes at the bottom level precisely carry the text values ​​to be translated. Style attribute data is embedded on top of each layer of nodes, ensuring that style information and content are tightly bound in both physical storage and logical hierarchy. By adopting this hierarchical structure, the translation engine can naturally obtain contextual information based on the depth-first or breadth-first path when traversing nodes. For example, when dealing with nested table scenarios, the system can accurately identify whether a text content node belongs to an outer table or an inner cell, thus providing a natural structured basis for constructing the translation context.

[0069] Optionally, considering the differences in underlying encoding between different document formats, the hierarchical structured data model described above can be implemented as a JSON object tree or a YAML hierarchical structure, in addition to using Extensible Markup Language (EXPLAIN), as long as the structure can support nested storage of text content nodes and embedded associations of style attribute data. In a specific implementation using a JSON object tree, each text content node is instantiated as a JSON object. This object contains a `text` field with the value of the text string to be translated, and a `style` field with the value of a nested dictionary. The `style` field records style attribute data such as font name, font size, color value, and spatial position in the form of embedded key-value pairs. The parent-child relationship between nodes is represented by a `children` array, and the sibling relationship is defined by the order of elements in the array. During the translation phase, the system extracts plain text from the `text` field of each JSON object. During the backfilling phase, only the target language translation string in the `text` field is updated, while the `style` field and the hierarchical nested structure of the JSON objects remain unchanged throughout the translation process, thus achieving atomic binding of text and style and high-fidelity cross-format restoration. It should be noted that the above selection of encoding methods is only an example and is not intended to limit the specific encoding of this model. In practical implementation, the above data model can also adopt a custom hierarchical binary sequence format, which may have advantages in storage density and parsing efficiency at different levels. It should be understood that regardless of the specific encoding form used, this hierarchical structured data model should maintain the hierarchical traversability between nodes, enabling the translation stage to extract structural context for each text segment to be translated based on tree path information. This ensures that during the translation backfilling stage, each node can be correctly positioned according to the original hierarchical relationship during the target format rendering stage.

[0070] Optionally, the hierarchical relationship of text content nodes is defined by a tree node structure, which determines the affiliation by recording the parent node identifier and child node index, and supports top-down path traversal or horizontal sibling traversal.

[0071] Optionally, the above tree-like node structure can be implemented as a multi-way tree with parent pointer references. Each text content node, in addition to storing its own node identifier and the text value to be translated, also stores a reference identifier pointing to its parent node and an ordered set of references to its child nodes. When the system needs to construct a translation context for a specific text content node, it can traverse upwards along the parent pointer to the root node, thereby determining the logical partition or page level of the node. Simultaneously, it can traverse the set of sibling nodes under the same parent node to obtain adjacent text fragments, forming a coherent inter-sentence context. Furthermore, when the original document contains nested lists or multi-level heading structures, the tree-like node structure can accurately map their hierarchical relationships: outer list nodes serve as parent nodes, inner list item nodes serve as child nodes, and style attributes at each level are stored in an embedded manner along with the corresponding node. This structure effectively avoids the problem of missing nested semantics that is difficult to express in linear array storage methods, allowing the translation engine to accurately restore the original hierarchical layout of the document after backfilling the translation.

[0072] Optionally, text content nodes are organized hierarchically, including at least parent-child subordinate and sibling parallel relationships, to represent the structural subordination and paragraph adjacency of content components at different granularities within the document. Optionally, the aforementioned hierarchical relationships can specifically be a combination of parent-child subordinate and sibling parallel relationships. Parent-child subordinate relationships represent the inclusion and being included logic between document components; for example, a chapter node acts as the parent node, and multiple paragraph nodes attached to it act as child nodes. Sibling parallel relationships represent the sequential relationship between nodes at the same logical level; for example, the first and second paragraphs within the same chapter are sibling nodes. By explicitly maintaining these two relationships, the system can accurately determine the structural position of a text content node within the entire document during translation processing, such as whether it is inside a table, in a footnote area, or in the main text, and thus assign differentiated translation strategies and terminology databases to different areas. Furthermore, when the target language translation needs to be recombined into a target format document during the rendering stage, the system can mount each text content node back to its corresponding parent container according to the hierarchical relationship, ensuring that the layout hierarchy of the translation in the target document is completely consistent with that of the source document.

[0073] In an optional implementation, the hierarchical structured data model is a document object model, and the hierarchical structured data model is in XML format; wherein, text content nodes are XML element nodes, and style information is attached to the corresponding XML element nodes in the form of XML attributes; the XML tag structure and style attributes remain unchanged throughout the entire translation process of the text values ​​of the text content nodes. In this way, by representing the hierarchical data model as a document object model in XML format, style information is stored synchronously with text nodes in the form of XML attributes, and the constraint that the XML tag structure and style attributes remain unchanged throughout the translation process is utilized, the translation engine and style data are effectively isolated, fundamentally eliminating the risk of style corruption in the translated document.

[0074] Optionally, XML (Extensible Markup Language) format is selected in this embodiment as the specific grammatical implementation carrier for the unified intermediate representation. It reorganizes content and style information originally scattered across various heterogeneous document formats into structured markup text. It should be noted that the XML format used here is not limited to a specific industry-standard subset or version. It can be strict XML conforming to general specifications, or a lightweight XML constraint form with customizable tag names and attribute lists based on internal system needs. The core consideration for using XML format to carry the unified intermediate representation is that its syntax naturally supports hierarchical nesting of element nodes and the additional storage of attribute key-value pairs. This allows style information originally attached to Word style sheets, PDF coordinate instructions, or HTML Cascading Style Sheets to be translated into XML attribute data embedded within text content nodes. In the actual processing flow, the aforementioned XML intermediate file can be expanded into a complete node tree in memory using a DOM (Document Object Model)-based overall loading method, or processed using a sequential scanning method based on a streaming parsing interface. This disclosure does not limit the specific method used. Furthermore, to avoid semantic ambiguity caused by tags with the same name from different source formats during merging, this XML intermediate representation can also introduce a namespace differentiation mechanism. By assigning unique identifiers to the prefixes of tags from different sources, it ensures that the original source and rendering context of each node can be accurately identified in the subsequent rendering stage. The introduction of the XML format is not merely a unification at the syntactic level, but also establishes a verifiable, scalable, and traversable data exchange foundation for cross-format document translation.

[0075] Optionally, the data model can be instantiated as a Document Object Model (DOM), providing a standardized access interface for content and style through a tree-like object structure.

[0076] Optionally, the Document Object Model (DOM) in this embodiment serves as a specific implementation of a hierarchical structured data model, mapping the content and style relationships of the entire source document to a tree-like node hierarchy in memory. In this model, each XML element node is abstracted as an object instance with parent-child-sibling relationships, which the system can manipulate through standardized programming interfaces (such as node traversal, attribute reading and writing, depth-first search, etc.). Considering the frequent need to locate text content nodes and extract strings during the translation phase, using a DOM structure can significantly reduce the complexity of node retrieval, allowing the system to quickly filter the set of target nodes to be translated based on tag names or attribute values. It should be noted that the aforementioned Document Object Model is not limited to the complete set of interfaces defined in the full specification; it can also be a lightweight object tree tailored to the needs of this system, or even a DOM-like hierarchical mapping simulated based on other structured markup rules, as long as it maintains the embedded storage relationship between text nodes and style attributes. In one specific approach, the system can generate unique identifiers for DOM nodes (such as global path indexes or custom handles) during the parsing phase and use these identifiers for precise positioning during the post-translation backfilling phase, thereby avoiding the performance overhead of re-traversing the entire text. One objective of this embodiment is to introduce a document object model, which on the one hand shields the differences between documents of different formats within the parser, and on the other hand provides a unified memory operation view for subsequent translation and rendering modules, achieving a truly format-independent processing architecture.

[0077] Optionally, the above text content nodes are instantiated as XML element nodes, and the text string to be translated is encapsulated through element tags.

[0078] Optionally, in the unified intermediate representation of the aforementioned XML format, each text fragment to be translated is encapsulated within an independent XML element node, which defines the boundaries of its text content using start and end tags. In one implementation, if the source document is a business report with multi-level headings and body paragraphs, the parser can translate the first-level headings into... <block type="heading1">Nodes, and nested within them. <text>XML element nodes are used to carry specific heading strings; while for body paragraphs, they are used... <block type="paragraph">Each node is wrapped, and each sentence or phrase within it is mapped to an independent segment according to the sentence segmentation rules. <text>XML element nodes. It should be noted that the naming of the aforementioned XML element nodes is not limited to a fixed dictionary. It can be a generic node name defined according to the Document Object Model specification, or a semantic tag customized for a specific industry domain, as long as the semantics of the tags are consistent across all modules within the system. Furthermore, considering the need to accurately backfill the translated text to its original position after translation, each XML element node can be assigned unique node identification information during generation (e.g., encoded through the node's hierarchical path in the tree, or with an automatically generated sequence number attribute). This identification information remains unchanged throughout the entire translation process, thus providing a precise location anchor for subsequent translation backfilling. One objective of this embodiment is that by encapsulating text content separately as XML element nodes, the translation engine can directly recognize and extract plain text strings without parsing complex original formatting instructions. Simultaneously, it provides a clear attachment object for style information, achieving decoupled storage of content and style.

[0079] Optionally, the above style information can be appended to the corresponding XML element node as an XML attribute, and the typography features can be embedded and stored as key-value pairs.

[0080] Optionally, in the unified intermediate representation using XML as the grammatical carrier, all style information carried in the source document, such as font name, font size, color value, geometric coordinate position, and reading order, is translated into XML attributes corresponding to the text content node. Taking a specific layout document as an example, if the parser extracts a text block located at coordinates (100, 200) in the upper left corner of a PDF (Portable Document Format) file and uses SimSun 12-point black font, the system can map this text content to... <text>The system converts the coordinates, font, font size, and color of the XML element node into XML attributes such as x, y, font, size, and color, respectively, thus embedding the layout features and text content in key-value pairs. It's important to note that the naming rules and numerical formats of these XML attributes are not limited to expressions completely identical to the original document format. They can be standardized measurement values ​​after normalization (e.g., converting point coordinates to metric millimeters) or composite attribute names with specific business prefixes, as long as the rendering stage can recognize and reverse-engineer them. Furthermore, to protect these XML attributes from unauthorized modification or accidental deletion during the translation stage, the system takes a snapshot of the attribute set of the XML element node before sending the text to be translated into the translation engine. After the translation is backfilled, the system compares the current attribute values ​​with the snapshot record to verify that all XML attributes, except for the strings inside the text nodes, remain unchanged. By abstracting style information into XML attributes and implementing a locking verification mechanism, the path for the translation engine to access style data can be completely blocked at the data representation level, ensuring that the translated document maintains a high degree of consistency with the original document in terms of layout features.

[0081] Optionally, the XML tag structure and its style attributes remain unchanged throughout the translation process, blocking the translation engine from modifying non-text data.

[0082] Optionally, during the translation phase described above, when the system performs translation processing on the unified intermediate representation, it enforces that the translation engine only replaces the internal text values ​​of XML element nodes, and strictly prohibits touching the XML tag structure itself and the style attributes attached to each node. Specifically, after the text to be translated is extracted, the system inputs a sequence of plain text strings detached from XML context tags to the translation engine; before backfilling, the translated text returned by the translation engine must undergo format cleaning and comparison by the locking verification module. This locking verification module can detect whether angle brackets, attribute assignment fragments, or nested tag structures are accidentally mixed into the translated string through preset regular expressions or a state machine-based tag scanning mechanism; if such non-text symbols are detected, direct backfilling is refused and an exception handling process is triggered (e.g., issuing an alarm, stripping illegal tags, or resubmitting the translation). In another implementation, the system can also adopt an isolation strategy based on template placeholders, that is, after extracting the text, the original text is replaced with a placeholder with a unique identifier, so that the translation engine does not need to touch the real XML tags during the context-based translation process, and after the engine returns the result, it performs precise replacement based on the mapping relationship between the placeholder and the original text. One objective of this embodiment is to establish invariance constraints on XML tag structure and style attributes throughout the translation process. This prevents the translation engine from misinterpreting style tags as translatable content, thus avoiding misalignment of node levels caused by tag additions or deletions. In this way, the rendering stage can re-synthesize the target format document based on complete and unchanged style data.

[0083] In step S240, text is extracted from text content nodes in the unified intermediate representation, and the translation context is determined based on the structural semantic information of each text content node in the unified intermediate representation. In this way, constructing the translation context using the structural semantic information of the unified intermediate representation not only provides the translation engine with accurate semantic cues to eliminate lexical ambiguity but also maintains text coherence, significantly improving the accuracy of cross-format document translation.

[0084] For example, when the system traverses the unified intermediate representation, it identifies a text content node located at the title tag level, with adjacent text fragments being technical parameter items and chapter numbers, respectively. Based on this, the system marks the text content node as a title semantic type and extracts the adjacent text and document topic domain information. The system then constructs a translation context according to a preset context encoding rule, which defines the field composition, concatenation order, and separators of the structured context object: the content level identifier is encoded as a structure tag prefix, adjacent text fragments are concatenated in sequence to form a context paragraph, and document topic information is encoded as a topic identifier. Fields are separated by preset separators, and the concatenation order is fixed as structure tag prefix, context paragraph, and topic identifier. For example, for technical terms at the title level, the encoded context object contains '[Heading] Chapter Title [Context] Preceding: Technical Parameter Items; Following: Chapter Number [Theme] Computer Technology Field'. In another example, the system identifies a text content node at the paragraph level, with the preceding and following texts being a product feature introduction and a market application scenario, respectively. The constructed translation context object then contains '[Paragraph] Product Performance Description [Context] Preceding text: Product Feature Introduction; Following text: Market Application Scenario [Theme] Consumer Electronics'. In yet another example, the system identifies a text content node at the table cell level, with the preceding and following cell texts being a processor model and storage capacity, respectively. The constructed translation context object then contains '[Cell] Memory Capacity [Context] Preceding text: Processor Model; Following text: Storage Capacity [Theme] Hardware Configuration'. The text carrying this translation context is then fed into the translation engine, enabling the engine to select appropriate terminology translations based on the context, thereby significantly improving the accuracy of the translation.

[0085] Optionally, structural semantic information refers to a set of meta-information extracted from the hierarchical structure of the unified intermediate representation, used to describe the logical role and semantic relationships of text content nodes within a document. This is fundamentally different from style information, which only describes visual appearance. Functionally, structural semantic information provides translation engines with document-level semantic cues needed to disambiguate, enabling the engine to distinguish the meaning differences of the same word in different functional areas of the document. In terms of data structure, it can be appended to the attribute fields of text content nodes as key-value pairs, or mounted as independent semantic marker nodes in the hierarchical tree. Logically, structural semantic information is only related to the content hierarchy identifiers of text content nodes (such as titles, body text, list items), the relationship between adjacent text segments, and the document theme, excluding the physical coordinates of text blocks on the page or layout attributes such as color and font. Structural semantic information can be determined by the hierarchical position of text content nodes in the unified intermediate representation, the type of block they belong to, and the relationships between adjacent nodes. Content-level identifiers indicate the specific semantic role of the current text, such as a title, body paragraph, list item, or table cell, enabling the translation engine to adhere to the stylistic norms of the corresponding text type when selecting words and constructing sentences. Information about the relationship between adjacent text segments provides local contextual support. For example, in scenarios where product models and technical parameters appear consecutively, incorporating brand information from preceding text into the translation context of the current sentence can effectively eliminate ambiguity in the reference of proper nouns. It should be noted that the extraction of the above structural semantic information is not limited to a single dimension. In practice, the contextual depth can be further expanded based on document topic information or domain keywords, thereby providing more complete semantic clues for machine translation and ensuring that the translated text maintains logical coherence and terminological consistency at the discourse level.

[0086] Optionally, the translation context carries at least structural semantic information to provide the translation engine with supplementary semantic clues needed to disambiguate. Optionally, the translation context may include at least one of the following: the content hierarchy identifier of the text content node, information about the relationship between adjacent text segments, and document topic information. One objective of this embodiment is to reduce information entropy caused by a lack of context during translation processing by passing the semantic roles inherent in the hierarchical structure to the translation engine, and to maintain consistency in stylistics and terminology in the translation. For example, when the same word has different meanings at different levels, the translation engine can distinguish whether it belongs to everyday expression or technical terminology based on the content hierarchy identifier, thereby outputting a translation that better fits the original context. Furthermore, if a known entity noun is detected in the adjacent text before and after the current text content node, this entity noun can be sent to the translation engine as supplementary context to achieve referential resolution and enhanced semantic coherence. It should be noted that the specific composition of the translation context can be dynamically adjusted according to the interface capabilities of the translation engine or the complexity of the document; this disclosure is not limited to this.

[0087] In an optional implementation, before extracting the text from the text content nodes, the method further includes: separating the text to be translated from the unified intermediate representation, so that the translation processing only applies to the text to be translated. In this way, identifying and isolating valid text content from the unified intermediate representation in advance avoids the translation engine from encountering non-translatable elements, reducing invalid data input and significantly lowering the risk of mistranslating tags or metadata, thereby improving translation accuracy and execution efficiency.

[0088] In one implementation, when the system traverses the unified intermediate representation, it first distinguishes between text content nodes that carry semantics and attribute nodes that carry styles. Then, it extracts the string sequence inside the text content node as the text to be translated, while keeping the node label, style attribute name and its value completely in the intermediate representation and shielding them from the translation input, so that the data stream received by the translation engine only contains plain text fragments.

[0089] Optionally, the text to be translated is used to isolate valid strings from the intermediate representation to eliminate interference from non-translated elements in the translation process.

[0090] Optionally, the text to be translated can be the string content carrying actual semantics in the unified intermediate representation, such as the character data inside the text content node in the Extensible Markup Language Document Object Model. The recognition logic for this text to be translated can be based on the node type label. For example, the internal data of nodes named "text" or "content" can be included in the set to be translated, while the node's own label symbols, style attribute names, and their values ​​can be excluded. For example, the above separation process can also be combined with the linguistic features of the text content for filtering, retaining only fragments containing natural language characters and avoiding engine calls to symbol strings that have no actual translation meaning. It should be noted that the above filtering rules are just one example, and this disclosure is not intended to limit the composition of the separation strategy; in actual implementation, the unified intermediate representation can also be directly traversed and the complete string sequence of all text content nodes can be extracted as the text to be translated without additional filtering. Considering that the translation engine is prone to mistakenly taking the label symbols as the content to be translated when processing mixed text containing labels, the above separation steps aim to reduce the computational overhead of the engine in processing irrelevant characters on the one hand, and avoid rewriting labels or attribute names, which could lead to parsing errors in the subsequent rendering stage.

[0091] In an optional implementation, the translation context is determined based on the structural semantic information of each text content node in the unified intermediate representation. This includes: traversing the unified intermediate representation to determine at least one of the following: the content level identifier of the text content node, the relationship information between adjacent text segments, and the document topic information; constructing the translation context based on at least one piece of information; and feeding the text carrying the translation context into the translation engine. In this way, by attaching multi-dimensional structured context information to the text to be translated, not only can lexical polysemy be eliminated and the consistency of terminology translation be improved, but the translation engine can also generate more accurate translations based on discourse logic.

[0092] In one implementation, after traversing the unified intermediate representation, the system identifies a text content node located within a heading-level node, thus determining its content level identifier as a first-level heading. Simultaneously, it extracts the preceding text block as an overview and the following text block as a detailed description, and identifies the document's subject as computer technology. The system constructs this information into a translation context, which, along with the original text, is fed into the translation engine. This allows the engine to select accurate translations of technical terms based on the heading context and semantic relationships, significantly improving translation accuracy. Optionally, the content level identifier represents the hierarchical category of the text content node within the document's semantic structure, assisting the translation engine in recognizing text.

[0093] Optionally, the content level identifier can be the document object model node type corresponding to the text content node, such as a text block represented by a text block element node, a text fragment wrapped by a text content node, or a structured classification tag attached to the node. In one possible implementation, when traversing the unified intermediate representation, if the system identifies a text content node that is wrapped within a text block element node representing a heading level and has a heading attribute, then its content level identifier is determined to be a heading level; if the unit is located within a regular text block element node and has no special structural attributes, then it is determined to be a body paragraph level; if the unit is located in a set of nodes representing a list structure, then it is mapped to a list item level. It should be noted that the above level division is not intended to exhaustively list all possible document structures. In actual implementation, custom levels can be introduced according to specific domain requirements, such as summary levels, citation block levels, or footnote levels. One objective of this embodiment is to enable the translation engine to distinguish between the general meaning of the same word in the title context and its specific meaning in the body text context by providing the content level identifier, thereby avoiding translation deviations caused by semantic role confusion and improving the professional accuracy of the translation.

[0094] Optionally, the determination of content hierarchy identifiers can be based not only on the node type in the unified intermediate representation but also on a comprehensive judgment combined with style attribute data. It should be understood that different document formats encode hierarchical structures differently. Layout-based documents may rely on physical coordinates and font size to implicitly express hierarchical relationships, while streaming documents rely more on explicit tag nesting. Therefore, during the mapping to the unified intermediate representation, the parser can select different hierarchy recognition strategies based on the source document format type and append the recognition results to the corresponding text content nodes with a unified hierarchy identifier field. This ensures that the subsequent translation engine can receive semantically consistent structured hierarchy information regardless of the original format.

[0095] Optionally, the preceding and following text relationships describe the semantic association between text content nodes and the preceding and following texts, assisting the translation engine in establishing contextual coherence. Optionally, the preceding and following text segment relationship information can be the text content carried by the preceding sibling text content nodes and the following sibling text content nodes in the document tree model of the unified intermediate representation of the current text content node, or it can be a cross-text block element text reference with an adjacent position relationship in the physical typesetting order. In one possible implementation, after completing the depth-first traversal of the intermediate representation, the system records the string content of the preceding valid text node of a certain text content node as the preceding context, and records the string content of the following valid text node as the succeeding context; if the node is located inside a paragraph, it further extracts the tail text of the previous text block element node of the text block element node and the head text of the next text block element node to construct a wider range of adjacency relationships. It should be understood that the above adjacency relationships not only refer to strictly continuous uninterrupted text, but can also include text segments separated by a small number of formatting tags but still at the same syntactic level. Furthermore, when the translation engine receives a translation request carrying information about the relationship between adjacent text segments, it can infer the referent of pronouns, the initial definition of technical terms, and the semantic direction connected by logical connectors based on the context. This significantly reduces the probability of ambiguity caused by isolated translation and ensures the coherence and consistency of the translation at the discourse level.

[0096] Optionally, the document topic information summarizes the domain to which the source document belongs, helping the translation engine to establish global constraints in cross-domain terminology disambiguation.

[0097] Optionally, document topic information can be a classification tag extracted from the metadata fields of the source document, a domain identifier automatically generated after clustering analysis of high-frequency keywords within the document, or an industry category manually specified by the user when submitting a translation task. In one possible implementation, the system reads a preset topic field, such as cloud computing or biomedicine, from the metadata attributes of the root node of the unified intermediate representation, and sends this topic information as part of the translation context along with the text to be translated to the translation engine. If the source document does not carry explicit topic metadata, the system can traverse the text content nodes in the intermediate representation, extract high-frequency terms, and match them with a preset domain thesaurus to determine the document topic information. It should be noted that the above method of obtaining topic information is only an example. In actual implementation, it can also be inferred by combining the document's source URL, file path keywords, or user history behavior. One objective of this embodiment is that by introducing document topic information, the translation engine can prioritize the standard translation within the topic domain when faced with highly ambiguous professional terms, thereby significantly improving the accuracy and domain adaptability of terminology translation.

[0098] In step S250, translation processing is performed on the text carrying the translation context to obtain the corresponding target language translation. Thus, by attaching structural semantic context derived from a unified intermediate representation to the text during the translation processing stage, the translation engine can perform semantic disambiguation based on content hierarchy, adjacent text, and document topic, thereby significantly improving the accuracy and coherence of the translation.

[0099] In one implementation, the translation process may specifically include: packaging the list of texts to be translated and their corresponding structural semantic context information and sending them in batches to the translation engine. Specifically, the context information may include: (1) the content level identifier of each text segment, such as indicating whether the current text is a paragraph, title, or list item; (2) the relationship information between adjacent text segments; and (3) the document topic and domain information. After receiving the information, the translation engine performs disambiguation processing on polysemous words according to the above context. For example, in a context involving the financial field, polysemous terms will be preferentially processed as professional definitions of that field. In another implementation, the translation engine may also perform discourse-level referential resolution processing according to the relationship information between adjacent text segments: if the current text to be translated contains pronouns or omits the subject, the engine uses entity nouns in the preceding text segments to complete the missing semantic subject, thereby ensuring subject-verb agreement and logical coherence in the translation at the cross-sentence level. After completing at least one of the above context utilization processes, the translation engine returns a list of target language translations that correspond one-to-one with the texts to be translated.

[0100] Optionally, the above translation processing can send text carrying structural semantic context into a translation engine for conversion, generating a translation in the target language. Optionally, the specific implementation of the above translation processing can be flexibly configured according to the system deployment environment and data security policies. Considering that enterprise documents often contain sensitive business information, as a possible implementation, the above translation processing can be executed by calling a locally deployed translation model, thereby avoiding the uploading of the original text via the external network and ensuring data privacy and network security. As another implementation, text carrying translation context can also be sent in batches to a cloud-based machine translation application programming interface (API) to utilize the stronger computing power and richer corpus resources of the cloud to process large-scale documents. It should be noted that the above description of the translation engine deployment method is just one example, and this disclosure is not intended to limit the specific execution vehicle of the translation processing.

[0101] In step S260, the target language translation is backfilled into the corresponding text content node. Except for the text value of the text content node, the structure and style information of the unified intermediate representation remain unchanged. In this way, by accurately backfilling the target language translation while maintaining a constant structure and style, not only can formatting damage caused by accidental modification of tags or attributes during translation be avoided, but also seamless matching of the translation with the original layout can be ensured, significantly improving the reliability of document translation and the accuracy of layout restoration.

[0102] In one implementation, after completing the translation phase, the system obtains a sequence of target language translations that correspond one-to-one with the source language text. For the third text content node in the intermediate layer Extensible Markup Language (XML) document, whose source text is the English user guide title and corresponding translation is the Chinese user guide, the system locates this text content node based on the hierarchical path location reference recorded in Phase Two and replaces its internal text with the aforementioned Chinese translation. During this process, the system forcibly maintains the node's tag name, the category attribute of its parent block-level container, and the hierarchical relationship of adjacent nodes, without performing any operations to add or delete nodes or modify style attributes. Therefore, only the text of this text content node changes; the entire unified intermediate representation's topology and visual style metadata remain unaffected.

[0103] Optionally, backfilling is used to accurately write the target language translation into the corresponding text content nodes to complete cross-language text replacement and maintain document structure stability. Optionally, the backfilling process can be based on direct text value replacement based on the recorded position reference, or it can be based on node identifier mapping to complete the translation injection. Considering the need to ensure data consistency in batch translation scenarios, as a possible implementation, the system can backfill the target language translation one-to-one according to the unique identifier of each text content node. The aforementioned unique identifier can be a hierarchical path, node sequence number, or content hash key, and this disclosure is not limited to these. If the length of the translation is much longer than the source text, the system can modify only the text values ​​while maintaining the unified intermediate representation structure, and recalculate the layout based on the rendering stage. That is to say, backfilling is strictly limited to data updates at the text level, and never touches the tag structure, attribute definition, or node hierarchy relationship, thereby ensuring that the translation result can achieve high-fidelity layout restoration based on the original style attribute data during the rendering stage.

[0104] In an optional implementation, after backfilling the target language translation to the corresponding text content node, the method further includes: verifying that, apart from the text value of the text content node, the tag name, attribute name, and attribute value have not changed, and that no non-text nodes have been added or deleted. This verification mechanism effectively prevents accidental tampering with style metadata and ensures that the document structure is consistent with the original intermediate representation, avoiding layout errors or formatting corruption during the translation rendering stage.

[0105] In one implementation, once the machine translation engine completes text replacement and writes the target language string back to the unified intermediate representation, the system immediately initiates a lock verification process. Specifically, the verification program first compares the label identifiers of each element node before and after backfilling to confirm that the label names have not been replaced with other semantic labels; then it traverses the entire attribute set to check that the attribute name list has not been added or deleted, and that the values ​​corresponding to each attribute are completely consistent with those before backfilling; finally, it performs a depth-first scan of the document tree to count the number and type of non-text nodes. If it detects that an element node that was not originally present has been added, or that an original comment node or nested container node has been accidentally deleted, the verification is deemed to have failed and the current rendering process is blocked, thereby ensuring that the translated intermediate layer file maintains strict consistency with the parsing stage in terms of structure and style.

[0106] Optionally, this verification ensures that only text values ​​are modified during the translation backfilling process, while the tag attributes carrying style and structural information remain in their original state. Optionally, the objects of the above consistency verification can be tag identifiers in markup language elements, attribute key names of elements, and attribute values ​​recording font, font size, color, or position coordinates. Considering that when processing long texts in batches, translation engines may mistakenly identify strings with angle brackets as tag fragments and output structured tags due to format inference, this verification mechanism can detect such anomalies before the rendering stage by performing a snapshot comparison of the complete hierarchical structured data model after backfilling. As a possible implementation, this verification can cover not only attributes directly belonging to text content nodes but also global style attributes of upper-level container nodes, such as paragraph-level indentation, line spacing, or page size definitions, thereby comprehensively preventing the risk of style information being tampered with during the translation process.

[0107] Optionally, in addition to full snapshot comparison, this verification can also employ a lightweight summary information verification strategy. This involves calculating and temporarily storing the summary information of each element node's tag identifier, attribute key name, and attribute value before translation. After the translated text is backfilled, the summary is recalculated and compared with the stored values. Furthermore, if a change in an attribute value is detected, the system can further distinguish whether the change is a reasonable change within a preset whitelist or an unexpected abnormal change, and trigger an alarm or automatic rollback accordingly. It should be noted that the granularity of the above comparison can be refined to the level of a single text content node or aggregated to the level of a block containing multiple sibling nodes. This disclosure does not aim to limit the triggering timing or statistical scope of this verification.

[0108] Optionally, the above verification compares the number and type of non-text nodes before and after backfilling to prevent the introduction or loss of structural elements during translation. Optionally, the above non-text nodes may include, but are not limited to, element nodes, comment nodes, processing instruction nodes, and nested container nodes used to organize hierarchical relationships. In one implementation, after the translation backfilling is completed, the system can perform a traversal scan on the unified intermediate representation, count the total number and path distribution of each type of non-text node in the tree structure, and compare them item by item with the baseline image generated in the parsing stage. If the scan results indicate that the number of a certain type of node has increased, it usually means that the translation engine has mistakenly inserted additional structured tags into the translation; if the number has decreased, nodes may have been mistakenly merged or accidentally discarded. To avoid the failure of the entire document translation task due to a single node anomaly, when the above verification detects inconsistencies, it can only locate and mark the branch where the abnormal node is located, and output a debugging report containing the node path and difference details for subsequent manual review or automatic repair process calls.

[0109] In step S270, the target language translation and style information are recombined into a target format document based on the style information in the unified intermediate representation. This significantly improves the fidelity of cross-format layout restoration by reverse mapping and rendering the target language translation to the target format based on style attribute data, avoiding formatting errors and manual repair costs in the translated document.

[0110] In one implementation, when the target format is specified as a portable document format, the system calls the corresponding format renderer to extract the page coordinates, font names, and color attributes of each text element in the unified intermediate representation. It then uses a generation library to draw the translated text block by block at the corresponding page position, thereby generating an output document with a layout highly consistent with the source file. When the target format is a word processing document, the system re-injects the translated unified intermediate representation content into the corresponding document template, assembles the document content and style definitions according to the style attribute data recorded therein, and then packages them to generate the target file. When the target format is a Hypertext Markup Language (HTML) webpage, the system directly converts the unified intermediate representation into the target webpage file using predefined style sheet conversion rules.

[0111] Optionally, step S270 calls the corresponding renderer to synthesize the translation and style attributes into a target document, achieving high-fidelity layout restoration. Optionally, as the final output stage of the three-stage processing pipeline, step S270 first calls the corresponding format renderer based on the user-specified target format identifier, recombining the text values ​​and style attribute data embedded in the unified intermediate representation into a file structure conforming to the target format specification. In one implementation, when the target format is a portable document, the renderer extracts the geometric coordinates and font attributes of each text element, calls the generation library to draw the translated text block by block at the corresponding page position; in another implementation, when the target format is a word processing document, the system injects the text content into the document template according to the hierarchical structure of the unified intermediate representation, assembles the style definition, and packages it for generation. Furthermore, the system can also perform format compliance verification on the generated file, verify the integrity of the file structure, and output it to a specified path after the verification passes; if an exception occurs, a re-rendering or logging is triggered. It should be noted that the above rendering path and verification mechanism are only some examples, and more formats can be dynamically extended using a plug-in architecture. This disclosure is not intended to limit the rendering architecture.

[0112] In an optional implementation, the method further includes: extracting original text fragments and corresponding translated text fragments from the text content nodes of the unified intermediate representation after backfilling, and depositing the original text fragments and translated text fragments into a structured corpus; in subsequent translation tasks, if text matching the original text fragment is detected, the translated text fragment corresponding to the original text fragment in the structured corpus is reused to backfill the corresponding text content node; wherein, the entries in the structured corpus retain structural semantic information and corresponding style information. In this way, by depositing the translation results and reusing them in subsequent tasks, repeated translation of the same original text can be avoided, and the consistency of the translation can be ensured based on the retained structural semantic and style information, thereby improving the efficiency and terminology uniformity of batch document translation.

[0113] In one implementation, a company uses the aforementioned document processing method to batch translate product technical manuals. After the text content nodes in the first manual are translated and backfilled into a unified intermediate representation, the system automatically extracts the original text fragments and their corresponding target language translation fragments from each text content node. It then writes the correspondence between the two, along with structural semantic information such as the content hierarchy identifier of the text content node and the relationships between adjacent texts, into a structured corpus. Two weeks later, when translating the second product manual, the system detects that the text in a certain paragraph perfectly matches the original text fragment already stored in the corpus. It then directly backfills the corresponding translation fragment from the corpus into that text content node without needing to call the translation engine again. Furthermore, the style information associated with the translation fragment is accurately inherited, ensuring a high degree of consistency in the presentation of the same technical descriptions in both manuals.

[0114] Optionally, a structured corpus is used to store the mapping relationship between the source text and the translation, allowing for direct reuse of the accumulated translations in subsequent translation tasks. Optionally, this structured corpus can be a data container based on a key-value pair structure or an index database supporting full-text search; its specific implementation can be flexibly determined based on the actual data scale and query performance requirements. In one implementation, in addition to the text content of the source and translation fragments, the corpus may also contain extended information such as the node path of each fragment in a unified intermediate representation, its content level identifier, and style attribute data. This extended information can assist the system in judging the context matching degree during the reuse stage, avoiding semantic deviations caused by mechanical reuse in different structural positions. It should be noted that the above description of the underlying storage structure of the corpus is only one example, and this technical solution is not intended to limit the storage form. Furthermore, the corpus can be deployed on a local server or connected to a distributed caching cluster to achieve efficient sharing and real-time synchronization of translation fragments when multiple users are translating documents concurrently.

[0115] Optionally, considering that the same original sentence may appear in multiple different types of source documents in a batch document translation scenario, as a possible implementation, each entry in the aforementioned structured corpus can be associated with the document format identifier, domain topic information, and translation timestamp of the original text fragment when it first appeared. To avoid ambiguous mismatches caused by simple text matching, when the system detects candidate matches in subsequent translation tasks, it can prioritize retrieving entries with the same or similar domain topics as the current document for reuse. That is, even if the strings of two original text fragments are completely identical, if there are significant differences in their content level identifiers or if the domain topics of the documents they belong to are different, the system can also make differentiated judgments based on the structural semantic information recorded in the entry, thereby selecting the most suitable translation fragment for backfilling, or marking it for manual review. This technical solution does not limit this.

[0116] Optionally, corpus entries retain the structural and semantic information and style information corresponding to the original text, which are used to perform differentiated backfilling based on contextual matching during reuse. By embedding style information and translated text fragments together in corpus entries, when subsequent translation tasks match the text and perform reuse, the system can directly backfill the historical translation and its associated style attribute data into the target text content node, without needing to re-match during the rendering stage or manually specify font, font size, color, and paragraph alignment. This mechanism enables the same content to automatically inherit the original layout features when reused in different target documents, significantly reducing the workload of typesetting and proofreading of translated documents, and completely eliminating cross-document layout inconsistencies caused by missed style adjustments during manual reuse, thus improving the consistency of batch document translation.

[0117] Optionally, considering that matching based solely on the string content of the original text fragment may lead to polysemy or semantic discrepancies in different contexts, as a possible implementation, the aforementioned structural semantic information may at least include the content hierarchy identifier of the original text fragment, the relationship information between adjacent text fragments, and the document topic information. The aforementioned style information may include style attribute data such as font name, font size, color value, and position coordinates. In actual reuse, the system not only compares string similarity but also determines whether the position of the current text to be translated and the historically saved text in the document structure is consistent based on the hierarchy identifier recorded in the entry. The underlying logic for determining consistency is: whether the content hierarchy identifier strings of the two are completely identical, and whether the domain classification of the document topic information belongs to the same preset topic category; if the strings are completely identical and the domain classification is the same, then it is determined to be consistent; otherwise, it is determined to have significant differences. For example, if the hierarchy identifier of the current text to be translated and the historically saved text are both 'paragraph' and the document topic is both 'computer technology field', then the system determines that they are consistent and directly reuses the translation. In another example, the current text to be translated has a hierarchy identifier of 'heading1' while the historical text has a hierarchy identifier of 'paragraph'. Although the string content is the same, the hierarchy identifiers are different, which the system determines as a significant difference and refuses to reuse directly. If there are significant differences in hierarchy identifiers or domain topic information, even if the strings match perfectly, the system can refuse to reuse directly or trigger a manual review process, thereby effectively avoiding the risk of mistranslation caused by ignoring the context.

[0118] Corresponding to the above method embodiments, this invention provides a document processing apparatus, see [link to previous document]. Figure 3 According to one embodiment of the document processing apparatus of this disclosure, the apparatus may include: The document retrieval module is used to retrieve source documents; The parsing and mapping module is used to parse the source document, extract the text content and style information, and map it into a unified intermediate representation. The unified intermediate representation includes the text content nodes that carry the text and the style information. The storage module is used to embed and store the style information in the unified intermediate representation as style attribute data within the text content nodes. The context determination module is used to extract text from text content nodes in the unified intermediate representation and determine the translation context based on the structural semantic information of each text content node in the unified intermediate representation. The translation processing module is used to perform translation processing on text carrying translation context and obtain the corresponding target language translation; The translation backfilling module is used to backfill the target language translation into the corresponding text content node. Except for the text value of the text content node, the structure and style information of the unified intermediate representation remain unchanged. The document synthesis module is used to re-synthesize the target language translation and style information into a target format document based on the style information in the unified intermediate representation.

[0119] In this way, by unifying the intermediate representation and embedding the style attribute data, it helps to reduce the data processing pressure in the process of independent parsing and translating multi-format documents, reduce the computational overhead of style reconstruction in the rendering stage, and improve the accuracy of translation context construction and the consistency of style restoration.

[0120] The specific details of each part of the above-mentioned device have been described in detail in the method section of the implementation plan. For any undisclosed details, please refer to the implementation plan of the method section, and therefore will not be repeated here.

[0121] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to exemplary embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0122] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure.

[0123] The following is a detailed reference. Figure 4 The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present disclosure. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 1201, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1202 or a program loaded from memory 1208 into random access memory (RAM) 1203. The RAM 1203 also stores various programs and data required for the operation of the electronic device. The processor 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0124] Typically, the following devices can be connected to I / O interface 1205: input devices 1206 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1207 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 1208 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1209. Communication device 1209 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0125] In particular, according to one embodiment of this disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, one embodiment of this disclosure includes a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication device 1209, or installed from memory 1208, or installed from ROM 1202. When the computer program is executed by processor 1201, it performs the functions defined in the methods described above in various embodiments of this disclosure.

[0126] Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0127] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded over a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0128] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0129] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.< / text> < / text> < / block> < / text> < / block>

Claims

1. A document processing method characterized by, The method includes: Get the source document; The source document is parsed to extract text content and style information, and mapped to a unified intermediate representation. The unified intermediate representation includes text content nodes that carry the text and the style information. The style information in the unified intermediate representation is stored embedded in the text content node in the form of style attribute data. The text is extracted from the text content nodes from the unified intermediate representation, and the translation context is determined based on the structural semantic information of each text content node in the unified intermediate representation. Perform translation processing on the text carrying the aforementioned translation context to obtain the corresponding target language translation; The target language translation is backfilled into the corresponding text content node, wherein, except for the text value of the text content node, the structure and style information of the unified intermediate representation remain unchanged; Based on the style information in the unified intermediate representation, the target language translation and the style information are recombined into a target format document.

2. The method of claim 1, wherein, The source document is in spreadsheet format, and the spreadsheet format uses a shared string structure to store text content; the shared string structure includes a shared string table, and each string entry in the shared string table is referenced by each cell in the worksheet through an index value; The process of parsing the source document, extracting text content and style information, and mapping it to a unified intermediate representation includes: Read each string entry in the shared string table and extract the style attribute data associated with each string entry in the source document as the style information; Each string entry is mapped to a text content node in the unified intermediate representation, the style information is mapped to style attribute data embedded in the corresponding text content node, and the index value is stored in the unified intermediate representation; The step of recombining the target language translation and the style information into a target format document based on the style information in the unified intermediate representation includes: The translated string entries in the shared string table of the source document are updated according to the index value, so that all cells referencing the same string entry synchronously obtain the target language translation; The index reference relationship between the cells in the worksheet and the string entries in the shared string table remains unchanged throughout the translation process.

3. The method according to claim 1, characterized in that, The source document is in presentation document format; parsing the source document, extracting text content and style information, and mapping it to a unified intermediate representation includes: The source document is read at the slide level, and the content nodes, paragraph-level attribute nodes, and text-level attribute nodes that carry the text are identified. The paragraph-level attribute nodes define the overall style features of the text block, and the text-level attribute nodes define the local style features of the text fragment. The text in the content node is mapped as the text content to the text content node in the unified intermediate representation, and the paragraph-level attribute node and the text-level attribute node are respectively mapped to the style attribute data embedded in the corresponding text content node.

4. The method according to claim 1, characterized in that, Before extracting the text from the text content node, the method further includes: The text to be translated is separated from the unified intermediate representation, so that the translation process is applied only to the text to be translated.

5. The method according to claim 1, characterized in that, After backfilling the target language translation into the corresponding text content node, the method further includes: Verify that, apart from the text value of the text content node, the tag name, attribute name, and attribute value have not changed, and no non-text nodes have been added or deleted.

6. The method according to claim 1, characterized in that, The step of determining the translation context based on the structural semantic information of each text content node in the unified intermediate representation includes: Traverse the unified intermediate representation to determine at least one of the following: the content level identifier to which the text content node belongs, the relationship information between adjacent text segments, and the document topic information; The translation context is constructed based on at least one of the aforementioned pieces of information; The text carrying the translation context is fed into the translation engine.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Extract the original text fragments and corresponding translated text fragments from the text content nodes of the unified intermediate representation after backfilling, and precipitate the original text fragments and the translated text fragments into a structured corpus; In subsequent translation tasks, if text matching the original text fragment is detected, the translated text fragment corresponding to the original text fragment in the structured corpus is reused to fill the corresponding text content node. The entries in the structured corpus retain the structural semantic information and the corresponding style information.

8. A document processing apparatus, characterized in that, include: The document retrieval module is used to retrieve source documents; The parsing and mapping module is used to parse the source document, extract text content and style information, and map them into a unified intermediate representation. The unified intermediate representation includes text content nodes that carry the text and the style information. The storage module is used to embed and store the style information in the unified intermediate representation as style attribute data within the text content node; The context determination module is used to extract the text from the text content nodes from the unified intermediate representation and determine the translation context based on the structural semantic information of each text content node in the unified intermediate representation. The translation processing module is used to perform translation processing on the text carrying the translation context and obtain the corresponding target language translation; The translation backfilling module is used to backfill the target language translation to the corresponding text content node, wherein, except for the text value of the text content node, the structure and style information of the unified intermediate representation remain unchanged; The document synthesis module is used to re-synthesize the target language translation and the style information into a target format document based on the style information in the unified intermediate representation.

9. An electronic device, characterized in that, include: Memory stores computer-executable instructions that can be executed by a processor; A processor for executing the computer-executable instructions to implement the method as claimed in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The device contains a computer program that, when executed by a processor, implements the method as described in any one of claims 1-7.

Images