Multi-language entry management method, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a multi-language entry management method, electronic equipment and a storage medium. The method comprises the steps that a structured form file is constructed to serve as a unified data source of multi-language entries, wherein the structured form file comprises a key column used for storing a unique key name and a plurality of language columns used for storing translation texts of all languages; reading the structured table file, constructing a mapping relationship between a key name and a translated text for each language type, and generating a corresponding language entry file; and reading the plurality of language entry files, extracting and combining mapping relationships between key names and translated texts in the files, and generating the structured form file. By means of the mode, centralized management and bidirectional reversible conversion of the multi-language entries can be achieved, development and maintenance cost is reduced, multi-language consistency and quality are improved, and proofreading and auditing of the entries are facilitated.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of software development, and in particular to a multilingual glossary management method, electronic device, and storage medium. Background Technology

[0002] With the globalization of the Internet and software systems, multilingual internationalization support has become a basic requirement for front-end and embedded interface development.

[0003] In actual development, the most common practice is to maintain separate JSON files for different languages, with each file storing a set of key-value translation entries. Specifically, developers create separate JSON files for each language in their projects; for example, zh-CN.json stores Chinese entries, en.json stores English entries, and fr.json stores French entries. A unified key is used across the different JSON files to map the translations of the same entry in different languages. The front-end uses this key to read the corresponding language file, enabling dynamic switching of the interface text.

[0004] However, the aforementioned distributed JSON management approach has significant shortcomings. Firstly, different language versions of the same term are stored in separate files, and the same key may be arranged differently in different language files. This makes it difficult for developers to perform cross-checking of all keys across different language files, and also makes it difficult to perform consistency checks such as key difference detection, empty text detection, and duplicate definition detection. Secondly, many existing projects already use distributed JSON file structures. Introducing a unified management mechanism would require manually comparing, organizing, and merging multiple language files, which is not only costly and time-consuming, but also prone to omissions and errors. Summary of the Invention

[0005] The main technical problem solved by the embodiments of the present invention is to provide a multilingual term management method, electronic device and storage medium, which can solve at least some of the defects of existing multilingual international term management.

[0006] In a first aspect, embodiments of the present invention provide a multilingual term management method, comprising: constructing a structured table file as a unified data source for multilingual terms; the structured table file includes a key column and multiple language columns, the key column being used to store unique key names for terms, and the language columns being used to store translated texts in each language corresponding to the key names; reading the structured table file, parsing and identifying the language types corresponding to each language column, constructing a mapping relationship between key names and translated texts for each language type, and generating corresponding language term files based on the mapping relationship; reading multiple language term files, identifying the language types corresponding to each language term file, extracting and merging the mapping relationship between key names and translated texts in each language term file, and generating the structured table file.

[0007] Optionally, the step of reading the structured table file, parsing and identifying the language type corresponding to each language column, constructing a mapping relationship between key names and translated text for each language type, and generating a corresponding language entry file based on the mapping relationship includes: reading the structured table file and creating a corresponding dictionary for each language type; verifying the content format of the structured table file, parsing the table header and identifying each language column; reading the structured table file row by row, performing data verification and processing on each row, and writing the key names and translated text into the corresponding dictionary; and generating a corresponding language entry file based on the content of each dictionary.

[0008] Optionally, the step of reading the structured table file line by line and performing data verification and processing on each line includes: determining whether the current line is a reserved line, and if so, skipping the current line; verifying whether the key name of the current line is duplicated, and if duplicated, logging and skipping the current line; generating the key name according to preset rules; the preset rules include ID encoding, naming prefix or naming suffix.

[0009] Optionally, before writing the key name and the translated text into the corresponding dictionary, the method further includes: cleaning the translated text; the cleaning process includes at least one of removing spaces, removing extra line breaks, and processing special characters; determining whether the translated text is missing, and if it is missing, setting the translated text to an empty string.

[0010] Optionally, the step of reading multiple language entry files, identifying the language type corresponding to each language entry file, extracting and merging the mapping relationship between key names and translated text in each language entry file, and generating the structured table file includes: creating a general dictionary and a set for recording all key names; reading each language entry file one by one, verifying the content format, identifying the language type according to the file name, storing the key-value content of each language entry file into the general dictionary, merging the key names into the set; and generating the structured table file based on the general dictionary and the set.

[0011] Optionally, generating the structured table file based on the total dictionary and the set includes: creating a table header and writing a header row in the order of key names and all language types; traversing all key names in the set and searching for the corresponding translation text in each sub-dictionary of the total dictionary for each key name; if the search fails, setting the translation text to an empty string; and writing the key names and the translation text corresponding to each language type column by column to generate the structured table file.

[0012] Optionally, the method further includes: generating a log file; the log file is used to record at least one of the following: execution process, skipped line information, exception information, and inconsistency information; automatically generating corresponding translation text for key names where the translation text is empty, and marking the automatically generated translation text.

[0013] Optionally, constructing a structured table file as a unified data source for multilingual entries includes: configuring the file format of the structured table file; the file format includes csv, xlsx, XML, YAML, or PO format; configuring the key columns and multiple language columns of the structured table file; and configuring extended columns as needed, the extended columns being used to store the remarks information corresponding to the key names.

[0014] In a second aspect, embodiments of the present invention provide an electronic device, comprising: at least one processor; at least one network interface communicatively connected to a corresponding processor; and a memory communicatively connected to the at least one processor; wherein the network interface is used to establish a communication connection between the processor and other external devices; the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the multilingual term management method as described in the first aspect.

[0015] Thirdly, embodiments of the present invention provide a non-volatile computer storage medium storing computer-executable instructions, which are executed by one or more processors, causing the one or more processors to perform the multilingual term management method as described in the first aspect.

[0016] The beneficial effects of the embodiments of the present invention (LJ2513601) are as follows: Unlike the prior art, the embodiments of the present invention can realize centralized management and bidirectional reversible conversion of multilingual entries, reduce development and maintenance costs, improve multilingual consistency and quality, and facilitate entry proofreading and auditing. Attached Figure Description

[0017] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0018] Figure 1 This is a flowchart illustrating a multilingual term management method provided by an embodiment of the present invention; Figure 2 This is a sub-flowchart of step S100 of the multilingual entry management method provided in the embodiments of the present invention; Figure 3 This is a sub-flowchart of step S200 of the multilingual term management method provided in the embodiments of the present invention; Figure 4 This is a sub-flowchart of step S300 of the multilingual entry management method provided in the embodiments of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Detailed Implementation

[0019] To facilitate understanding of this application, a more detailed description is provided below with reference to the accompanying drawings and specific embodiments. It should be noted that when an element is described as being "fixed to" another element, it can be directly on the other element, or one or more intermediate elements may exist between them. When an element is described as being "connected" to another element, it can be directly connected to the other element, or one or more intermediate elements may exist between them. The terms "upper," "lower," "inner," "outer," "bottom," etc., used in this specification indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0020] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0021] Furthermore, the technical features involved in the different embodiments of this application described below can be combined with each other as long as they do not conflict with each other.

[0022] The technical solutions in this application will be described below with reference to the accompanying drawings.

[0023] See Figure 1 In some embodiments of this application, a multilingual term management method is provided, which specifically includes the following steps: Step S100: Construct a structured table file as a unified data source for multilingual entries.

[0024] In some embodiments of this application, the structured table file includes a key column and multiple language columns. Specifically, the key column is used to store the unique key name of each term, and the language columns are used to store the translated text of each language corresponding to the key name.

[0025] In this context, a structured table file refers to a data file with a row and column structure, used for centralized storage and management of multilingual terminology content. Key columns are columns in a structured table file used to store unique identifiers for terms. Language columns are columns in a structured table file used to store translations of terms in specific languages; each language column corresponds to one language. Key names are unique identifiers for terms, used to establish correspondences between different languages. Translated text refers to the translation of a key name in a specific language.

[0026] It's easy to understand that by storing multilingual entries centrally in a structured table file, unified management of multilingual content can be achieved, making it easier for developers to view, modify, and review all language versions in a single file.

[0027] In some embodiments of this application, when constructing the structured table file in step S100, the system can provide a graphical user interface.

[0028] A graphical user interface (GUI) refers to an interface that allows users to interact with each other through visual elements such as windows, buttons, and menus.

[0029] Specifically, users can use a graphical interface to select the storage location of the structured table file, the configuration file format, and set parameters such as the key column and language column. It's easy to understand that providing a graphical interface lowers the barrier to entry for users, making it easier for non-technical personnel to operate the system.

[0030] As an example rather than a limitation, a graphical user interface may include interactive elements such as a file selection dialog box, a format configuration drop-down menu, and a language column add button, allowing users to complete the construction and configuration of structured table files by clicking and selecting.

[0031] Step S200: Read the structured table file, parse and identify the language type corresponding to each language column, construct a mapping relationship between key names and translated text for each language type, and generate the corresponding language entry file based on the mapping relationship.

[0032] In some embodiments of this application, after reading the structured table file, the table header is first parsed to identify the language type corresponding to each language column.

[0033] Here, "language type" refers to the specific language identifier corresponding to the language column, used to distinguish different languages. "Mapping relationship" refers to the correspondence between key names and translated text. The language glossary file is a file that stores the mapping relationships between all key names and translated text for a specific language.

[0034] Specifically, for each language type, a mapping relationship between key names and translated text is constructed, and corresponding language entry files are generated based on the mapping relationship for each language type.

[0035] It is easy to understand that step S200 realizes the forward conversion from a unified structured table file to a multi-language glossary file, so that developers only need to maintain one structured table file to automatically generate the multi-language glossary file required for the project.

[0036] Step S300: Read multiple language entry files, identify the language type corresponding to each language entry file, extract and merge the mapping relationship between key names and translated text in each language entry file, and generate a structured table file.

[0037] In some embodiments of this application, after reading multiple language entry files, the language type corresponding to each language entry file is first identified. Specifically, the mapping relationship between key names and translated text is extracted from each language entry file, and the mapping relationships of each file are merged. A structured table file is generated based on the merged mapping relationship.

[0038] It is easy to understand that step S300 realizes the reverse restoration from multiple scattered language entry files to a unified structured table file, so that the multilingual entry files in the existing project can be integrated into a unified structured table file, which facilitates subsequent consistency detection and entry proofreading.

[0039] Steps S200 and S300 together constitute a bidirectional reversible conversion mechanism, enabling bidirectional synchronous management of multilingual entries between structured table files and language entry files. For new projects, step S100 can be executed first to build a structured table file, and then step S200 can be used to generate language entry files; for existing projects, step S300 can be used to reverse-engineer the scattered language entry files back into structured table files, and then they can be incorporated into the unified management system.

[0040] The multilingual term management method provided in this embodiment constructs a structured table file as a unified data source and realizes bidirectional reversible conversion between the structured table file and the language term file based on two modes: forward conversion and reverse restoration. This solves the problems of difficulty in consistency verification and difficulty in migrating old projects in the existing technology of decentralized management.

[0041] In some embodiments of this application, the multilingual term management method further includes the following steps: Step S400: Generate a log file, which is used to record at least one of the following: execution process, skipped line information, exception information, and inconsistency information.

[0042] In some embodiments of this application, during the execution of step S200 or step S300, the system synchronously generates a log file.

[0043] The log file refers to a file used to record various information during the execution of the method. The execution process refers to the status information of step S200 or step S300 during runtime. Skipped line information refers to records of lines skipped due to non-compliance with rules when reading the structured table file line by line. Exception information refers to records of errors or exceptions that occur during execution. Inconsistency information refers to records of inconsistencies such as key name differences or missing translated text between different language terminology files.

[0044] Specifically, log files can record at least one of the following: execution process, skipped line information, exception information, and inconsistency information. It's easy to understand that by generating log files, developers can quickly locate problems and perform secondary checks, facilitating traceability and version management.

[0045] As an example and not a limitation, during the forward conversion process in step S200, the log file can record information such as skipped reserved lines, duplicate key names, and missing translated text; during the reverse restoration process in step S300, the log file can record inconsistencies such as key name differences between language terminology files and missing translated text.

[0046] Step S500: For key names where the translation text is empty, automatically generate the corresponding translation text and mark the automatically generated translation text.

[0047] In some embodiments of this application, during the execution of step S200 or step S300, the system detects key names where the translation text is empty and automatically generates the corresponding translation text.

[0048] Here, "empty translation text" refers to a key name in a structured table file or language glossary file where there is no corresponding translation content for a specific language column. "Automatic generation" means the system automatically generates corresponding translation content for missing translation text. "Marking" refers to adding special identifiers to automatically generated translation text to distinguish it from manually translated content.

[0049] Specifically, the system first detects keys in the structured table file where the translation text is empty, then automatically generates the corresponding translation text and marks it. It's easy to understand that marking the automatically generated translation text facilitates secondary proofreading and correction by humans, ensuring translation quality.

[0050] As an example rather than a limitation, automatically generated translated text can be marked by adding specific prefixes, suffixes, or special symbols to indicate to developers or translators that the content is automatically generated and requires manual review.

[0051] This embodiment, based on the aforementioned multilingual term management method, supplements it with log file generation and automatic translation text generation functions. The log file records various information during the execution process, facilitating problem localization and secondary proofreading; the automatic translation text generation function can automatically fill in missing translation content and distinguish between manually translated and automatically generated content through marking, facilitating subsequent manual review and correction, thereby improving the efficiency and quality of multilingual term management.

[0052] See Figure 2 In some embodiments of this application, a specific implementation of step S100 is provided. Step S100, which constructs a structured table file as a unified data source for multilingual entries, specifically includes the following steps: Step S110: Configure the file format of the structured table file.

[0053] In some embodiments of this application, when constructing a structured table file, it is first necessary to configure the file format of the structured table file.

[0054] The file format refers to the data storage format used by the structured table file, which defines the file's structure and encoding method.

[0055] Specifically, file formats include csv, xlsx, XML, YAML, or PO formats. It's easy to understand that different file formats are suitable for different application scenarios and development environments; by supporting multiple file formats, the needs of different projects can be met.

[0056] As examples, not limitations, CSV is a comma-separated value format, characterized by its simple structure and ease of processing; XLSX is an Excel spreadsheet format, supporting rich table functions and styles; XML is an Extensible Markup Language format, with good readability and extensibility; YAML is a human-readable data serialization format, often used for configuration files; and PO is a Portable Object format, often used in internationalization translation scenarios.

[0057] Step S120: Configure the key columns and multiple language columns of the structured table file.

[0058] In some embodiments of this application, after configuring the configuration file format, it is necessary to configure the key columns and multiple language columns of the structured table file.

[0059] Specifically, the key column stores the unique key name of each term, and the multiple language columns store the corresponding translated text in each language. It's easy to understand that by configuring the key column and multiple language columns, a correspondence can be established between the key name and the translated text in each language.

[0060] In some embodiments of this application, extended columns can also be configured as needed.

[0061] Among them, extended columns refer to columns that are configured additionally according to actual needs, in addition to key columns and language columns.

[0062] Specifically, extended columns are used to store notes corresponding to the key names. It's easy to understand that configuring extended columns increases the information richness of the original record file, making it easier for developers to record contextual information, translation notes, or other auxiliary information for entries.

[0063] As an example, and not a limitation, extended columns may include notes, status, priority, etc. Notes columns are used to record supplementary information or translation tips for the entry; status columns are used to indicate the translation status of the entry, such as translated, pending review, pending translation, etc.; priority columns are used to indicate the translation priority of the entry, making it easier for translators to translate according to priority.

[0064] This embodiment provides a specific implementation of step S100. Step S110 configures the file format of the structured table file, supporting multiple formats such as csv, xlsx, XML, YAML, or PO to adapt to the needs of different projects. Step S120 configures the key column and multiple language columns, establishes the correspondence between key names and translated text in each language, and can configure extended columns to store notes as needed, thereby increasing the information richness and flexibility of the structured table file.

[0065] See Figure 3In some embodiments of this application, a specific implementation of step S200 is provided. Step S200 reads the structured table file, parses and identifies the language type corresponding to each language column, constructs a mapping relationship between key names and translated text for each language type, and generates the corresponding language entry file based on the mapping relationship. Specifically, it includes the following steps: Step S210: Read the structured table file and create a corresponding dictionary for each language type.

[0066] In some embodiments of this application, when performing forward conversion, a structured table file is first read and a corresponding dictionary is created for each language type.

[0067] A dictionary is a data structure used to store the mapping relationship between key names and translated text, with each dictionary corresponding to a language type.

[0068] Specifically, the system creates a corresponding number of dictionaries based on the number of language columns contained in the structured table file. It's easy to understand that by creating a separate dictionary for each language type, the mapping between language keys and translated text can be stored separately, facilitating the subsequent generation of corresponding language glossary files.

[0069] As an example, and not a limitation, if a structured table file contains four language columns: Chinese, English, French, and German, the system creates four dictionaries to store the mapping relationship between the key names and the translated text for Chinese, English, French, and German, respectively.

[0070] Step S220: Verify the content format of the structured table file, parse the table header and identify each language column.

[0071] In some embodiments of this application, after creating the dictionary, it is necessary to verify the content format of the structured table file and parse the table header to identify each language column.

[0072] The content format refers to the data organization of a structured table file, including the column order and data types. The header is the first row of the structured table file, used to define the names and meanings of each column.

[0073] Specifically, the system first verifies whether the content format of the structured table file meets the preset requirements, and then parses the table header to identify the language type corresponding to each language column. It's easy to understand that by verifying the content format and parsing the table header, the system ensures the correctness of the data structure of the structured table file and accurately identifies the position of each language column and its corresponding language type.

[0074] As an example rather than a limitation, the language column identifier in the table header can use standard language codes, such as zh-CN for Simplified Chinese, en for English, fr for French, de for German, etc. The system will automatically identify the language type corresponding to each language column based on the language code in the table header.

[0075] Step S230: Read the structured table file line by line, perform data validation and processing on each line, and write the key name and translated text into the corresponding dictionary.

[0076] In some embodiments of this application, after parsing the table header and identifying each language column, the system reads the structured table file row by row, performs data verification and processing on each row, and writes the key name and translated text into the corresponding dictionary.

[0077] Data validation refers to the process of checking the legality of each row of data. Data processing refers to the process of cleaning, transforming, and other operations on each row of data.

[0078] Specifically, the system reads data row by row from the second row of the structured table file, skipping the header row. It performs data validation and processing on each row, and then writes the key names and the translated text for each language column into the corresponding language dictionary. It's easy to understand that by reading and processing row by row, the multilingual vocabulary data in the structured table file can be converted into a dictionary structure corresponding to each language type.

[0079] As an example rather than a limitation, for each row in a structured table file, the system first reads the key name in the key column, then reads the translated text in each language column in turn, and writes the correspondence between the key name and the translated text into the dictionary of the corresponding language type.

[0080] Step S240: Generate corresponding language entry files based on the contents of each dictionary.

[0081] In some embodiments of this application, after all lines have been read and processed, the system generates corresponding language entry files based on the contents of each dictionary.

[0082] Specifically, the system iterates through the dictionary corresponding to each language type, outputting the mapping relationship between the dictionary keys and the translated text as the corresponding language entry file. It's easy to understand that by generating language entry files based on the contents of each dictionary, a forward conversion from a unified structured table file to multiple independent language entry files can be achieved.

[0083] By way of example and not limitation, if the structured table file contains four language columns of Chinese, English, French, and German, the system generates four language entry files, namely zh-CN.json, en.json, fr.json, and de.json, according to the content of the four dictionaries. Each file contains the mapping relationship between all the key names and the translation texts in the corresponding language.

[0084] In some embodiments of the present application, when generating the corresponding language entry files according to the content of each dictionary in step S240, it further includes appending a timestamp to the output file name.

[0085] Here, the timestamp refers to a string recording the file generation time, usually containing time information such as year, month, day, hour, minute, and second.

[0086] Specifically, when the system generates the language entry files, it appends the timestamp of the current time to the file name. It is easy to understand that by appending a timestamp to the output file name, it can prevent the newly generated file from overwriting the existing file, which is convenient for tracing and version management.

[0087] By way of example and not limitation, if the current time is 10:30 on January 15, 2024, the language entry file names generated by the system can be zh-CN_20240115_1030.json, en_20240115_1030.json, etc. Developers can identify the generation time of the file according to the timestamp in the file name.

[0088] In some embodiments of the present application, the language entry files adopt the JSON format.

[0089] Here, the JSON format refers to the JavaScript Object Notation format, which is a lightweight data exchange format and is easy to read and write.

[0090] Specifically, the system outputs the mapping relationship between the key names and the translation texts in each dictionary as a language entry file in JSON format. Each key-value pair in the file represents the corresponding relationship between a key name and a translation text. It is easy to understand that the JSON format is the most commonly used internationalization entry storage format in front-end development. By generating language entry files in JSON format, it can be seamlessly docked with the existing front-end internationalization framework.

[0091] By way of example and not limitation, the content format of the generated zh-CN.json file is as follows: {"HomePage": "首页", "Settings": "设置", "About": "关于"}, where the key name is the unique identifier of the entry, and the value is the corresponding Chinese translation text.

[0092] This embodiment provides a specific implementation of step S200. Step S210 creates a corresponding dictionary for each language type. Step S220 verifies the content format and parses the table header to identify each language column. Step S230 reads the structured table file line by line, performs data verification and processing on each line, and writes the key name and translation text into the corresponding dictionary. Finally, step S240 generates the corresponding language entry file based on the contents of each dictionary, thereby achieving a forward conversion from a unified structured table file to multiple language entry files.

[0093] In some embodiments of this application, another specific implementation of step S200 is provided. Based on the previous specific implementation, this implementation further includes the following steps before writing the key names and translated text into the corresponding dictionary.

[0094] Step S221: Clean the translated text.

[0095] In some embodiments of this application, the system first cleans the translated text before writing the key names and translated text into the corresponding dictionary.

[0096] Among them, cleaning refers to the process of standardizing the translated text to remove invalid characters or formatting issues.

[0097] Specifically, the cleaning process includes at least one of removing spaces, removing extra line breaks, and handling special characters. It's easy to understand that cleaning the translated text ensures that the translated text written into the dictionary is formatted correctly and accurate, avoiding display anomalies or program errors caused by formatting issues.

[0098] As an example, not a limitation, removing spaces refers to removing redundant spaces at the beginning and end of the translated text, or removing multiple consecutive spaces in the translated text; removing redundant line breaks refers to removing unnecessary line breaks in the translated text, merging multiple consecutive line breaks into a single line break, or removing line breaks at the beginning and end of the translated text; special character processing refers to escaping, replacing, or deleting special characters in the translated text, such as handling quotation marks, slashes, escape characters, and other special characters that may affect the parsing of language entry files.

[0099] In some embodiments of this application, the cleaning process can be selected to perform one or more combinations of the above-described processing methods according to actual needs. It is easy to understand that different projects may have different format requirements for translated text; by flexibly configuring the cleaning process, the needs of different projects can be met.

[0100] Step S222: Determine if the translation text is missing. If it is missing, set the translation text to an empty string.

[0101] In some embodiments of this application, after cleaning the translated text, the system determines whether the translated text is missing.

[0102] In this context, "missing translation text" refers to a situation in a structured spreadsheet file where a key name has no corresponding translation content under a specific language column, or the translation content is blank. An empty string is a string of zero length used to indicate a temporarily missing translation text.

[0103] Specifically, the system checks whether the translated text in each language column of the current row contains valid content. If the translated text in a language column is missing or blank, the system sets that translated text to an empty string; if the translated text contains valid content, it retains the original content. It's easy to understand that by setting missing translated text to empty strings, the system ensures the integrity of the generated language entry file structure and avoids program errors caused by missing key-value pairs.

[0104] As an example, not a limitation, in real-world development scenarios, some entries may only have partial language translations completed, while translations in other languages ​​may be incomplete. By setting the missing translated text to an empty string, the language entry file ensures that all key names are included, facilitating subsequent identification and completion of missing translations by translators. Simultaneously, the system can record the missing translated text key names and their corresponding language types in the log file, allowing developers to track translation progress.

[0105] This embodiment provides preprocessing steps before writing the key names and translated text into the dictionary. By cleaning the translated text, including removing spaces, extra line breaks, and special characters, the format of the translated text can be ensured to be standardized. By determining whether the translated text is missing and setting the missing translated text to an empty string, the integrity of the language entry file structure can be ensured. The above steps together improve the standardization and completeness of the data during the forward conversion process.

[0106] In some embodiments of this application, a specific implementation of step S230 is provided. Step S230 involves reading the structured table file line by line, performing data validation and processing on each line, and includes the following steps.

[0107] Step S231: Determine if the current row is a reserved row; if so, skip the current row.

[0108] In some embodiments of this application, when reading a structured table file line by line, the system first determines whether the current line is a reserved line.

[0109] Reserved rows refer to rows that are reserved in advance in a structured table file and do not participate in the forward conversion process. They are usually used as placeholders or to mark special purposes.

[0110] Specifically, the system reads the content of the current line and determines whether it is a reserved line according to preset judgment rules. If the current line is a reserved line, it is skipped and the system continues to read the next line; if the current line is not a reserved line, the system continues to execute subsequent data verification and processing steps. It is easy to understand that by judging and skipping reserved lines, invalid data can be avoided from being written to the dictionary, ensuring the accuracy of the generated language entry file.

[0111] As an example rather than a limitation, reserved rows can be marked by entering specific identifiers in the key column, such as "Reserve", "Reserved", or identifiers that begin with a specific prefix. When the system recognizes a reserved identifier during reading, it will automatically skip the current row.

[0112] Step S232: Check if the key name of the current row is duplicated. If it is duplicated, log it and skip the current row.

[0113] In some embodiments of this application, after determining that the current row is not a reserved row, the system checks whether the key name of the current row is duplicated with the key name that has already been processed.

[0114] Duplicate key name refers to the situation where the key name of the current row is the same as the key name of a previously processed row.

[0115] Specifically, the system maintains a record of processed key names. When processing each row, it compares the key name of the current row with the recorded key names. If the key name of the current row already exists in the record, it is considered a duplicate key name, the system logs this and skips the current row; if the key name of the current row does not exist in the record, it is added to the record, and subsequent processing steps continue. It's easy to understand that by checking for duplicate key names, the uniqueness of key names can be ensured, avoiding the problem of duplicate definitions in the generated language entry file.

[0116] As an example, and not a limitation, the system can use a set data structure to record processed key names, leveraging the uniqueness of sets to quickly determine if key names are duplicated. When a duplicate key name is detected, the system records the specific content of the duplicate key name, the line number, and other information in the log file, facilitating subsequent investigation and correction by developers.

[0117] Step S233: Generate key names according to preset rules.

[0118] In some embodiments of this application, after verifying that the key name is not duplicated, the system generates a key name according to a preset rule.

[0119] Among them, preset rules refer to predefined rules used to generate or transform key names.

[0120] Specifically, the preset rules include ID encoding, naming prefixes, or naming suffixes. It's easy to understand that by generating key names according to these preset rules, key names can be standardized and unified, facilitating consistent management and use within the project.

[0121] As an example, not a limitation, the ID encoding rule refers to assigning a unique numeric or alphanumeric combination code to each key name; the naming prefix rule refers to adding a uniform prefix string before the original key name, such as "app_", "page_", etc., to distinguish entries from different modules or pages; the naming suffix rule refers to adding a uniform suffix string after the original key name, such as "_text", "_label", etc., to distinguish different types of entries. Developers can choose appropriate preset rules or combine multiple rules according to project needs.

[0122] This embodiment provides a specific implementation method for data verification and processing in step S230. By determining whether the current row is a reserved row and skipping the reserved row, invalid data can be filtered out; by verifying whether the key name is duplicated and logging and skipping the current row when duplicates are found, the uniqueness of the key name can be ensured; by generating key names according to preset rules, standardized management of key names can be achieved. The above steps together ensure the accuracy and consistency of data during the forward conversion process.

[0123] See Figure 4 In some embodiments of this application, a specific implementation of step S300 is provided. Step S300 reads multiple language entry files, identifies the language type corresponding to each language entry file, extracts and merges the mapping relationship between key names and translated text in each language entry file, and generates a structured table file, specifically including the following steps: Step S310: Create a master dictionary and a set to record all key names.

[0124] In some embodiments of this application, when performing reverse engineering, a master dictionary and a set for recording all key names are first created.

[0125] The master dictionary is a data structure used to store the content of all language entry files. It uses language type as the key and the corresponding sub-dictionaries for each language entry file as values. A sub-dictionary is a data structure that stores the mapping between keys and translated text within a single language entry file. A set is a data structure used to record the keys appearing in all language entry files; keys in a set are unique.

[0126] Specifically, before performing the reverse engineering, the system initializes an empty master dictionary and an empty set to store the data extracted from the glossary files of each language. It's easy to understand that by creating the master dictionary and set, a unified storage structure can be provided for subsequent data extraction and merging.

[0127] As an example rather than a limitation, the structure of the main dictionary can be represented as: main dictionary = {language type 1: sub-dictionary 1, language type 2: sub-dictionary 2, ...}, where each sub-dictionary stores the mapping relationship between the key names in the corresponding language entry file and the translated text; the set is used to summarize the key names that appear in all language entry files, ensuring that each key name is recorded only once.

[0128] Step S320: Read each language entry file one by one, verify the content format, identify the language type according to the file name, store the key-value content of each language entry file into the main dictionary, and merge the key names into the set.

[0129] In some embodiments of this application, after creating the general dictionary and set, the system reads the language entry files one by one and performs content format verification, language type identification, data storage, and key name merging.

[0130] Content format verification refers to the process of checking the legality of the data format of the language entry file. Filename recognition refers to the process of parsing the corresponding language type from the filename of the language entry file. Key-value content refers to the correspondence between key names and translated text stored in the language entry file.

[0131] Specifically, the system performs the following operations in sequence: First, it reads the current language vocabulary file; then, it verifies whether the content format of the current language vocabulary file meets the preset requirements; next, it identifies the corresponding language type based on the filename of the current language vocabulary file; then, it stores the content of the current language vocabulary file as a sub-dictionary, using the language type as the key, into the main dictionary; finally, it merges all the key names in the current language vocabulary file into a set. The system repeats the above operations until all language vocabulary files have been read.

[0132] It is easy to understand that by reading and processing language entry files one by one, the multilingual entry data scattered in various files can be aggregated into a total dictionary and set, providing a complete data foundation for the subsequent generation of structured table files.

[0133] As an example, and not a limitation, if the language entry files to be processed include four files: zh-CN.json, en.json, fr.json, and de.json, the system will read each file sequentially, identify the language type as zh-CN, en, fr, and de based on the filename, store the contents of each file as a sub-dictionary in the main dictionary, and merge the keys from each file into a set. If the keys in different language entry files are not completely identical, the set will contain the union of the keys that appear in all files.

[0134] Step S330: Generate a structured table file based on the total dictionary and sets.

[0135] In some embodiments of this application, after reading and processing all language entry files, the system generates a structured table file based on the total dictionary and set.

[0136] Specifically, the system generates a structured table file containing key columns and language columns based on the language types and their corresponding sub-dictionary contents stored in the master dictionary, combined with all the key names recorded in the set. It's easy to understand that by generating a structured table file from the master dictionary and set, it's possible to reverse-engineer multiple scattered language entry files into a unified structured table file.

[0137] As an example, and not a limitation, the generated structured table file contains all the key names in the set in the key column, and each language column contains the translated text of the corresponding language type sub-dictionary in the main dictionary. If a key name does not exist in the sub-dictionary of a specific language, the value of that key name in the corresponding language column can be set to an empty string.

[0138] In some embodiments of this application, when generating the structured table file in step S330, a timestamp is also appended to the output filename.

[0139] Specifically, when generating structured table files, the system appends a timestamp of the current time to the filename. It's easy to understand that appending a timestamp to the output filename prevents newly generated files from overwriting existing ones, facilitating traceability and version management.

[0140] As an example, and not a limitation, if the current time is 14:20 on January 15, 2024, the structured table file generated by the system can be named i18n_20240115_1420.xlsx or i18n_20240115_1420.csv. Developers can identify the generation time of the file based on the timestamp in the file name and retain historical versions for comparison and backtracking.

[0141] This embodiment provides a specific implementation of step S300. Step S310 creates a general dictionary and a set for recording all key names, providing a unified structure for data storage. Step S320 reads each language entry file, verifies the content format, identifies the language type based on the file name, stores the key-value content in the general dictionary, and merges the key names into the set, thus summarizing the multilingual entry data. Step S330 generates a structured table file based on the general dictionary and the set, completing the reverse restoration from multiple scattered language entry files to a unified structured table file.

[0142] In some embodiments of this application, a specific implementation of step S330 is provided. Step S330 generates a structured table file based on the general dictionary and the set, including the following steps.

[0143] Step S331: Create the table header and write the header row in the order of key name and all language types.

[0144] In some embodiments of this application, when generating a structured table file, the table header is first created and the header row is written in the order of key names and all language types.

[0145] In a structured table file, the header row is the first row and defines the names and meanings of each column. The title row is the row in the structured table file that contains the header content.

[0146] Specifically, the system creates table headers according to the language types contained in the overall dictionary, following a preset order. The first column of the header is the title of the key column, and subsequent columns are the titles of each language type. The system writes the created table headers into the first row of the structured table file as the header row. It's easy to understand that by creating table headers and writing them into the header row, the meaning of each column in the structured table file is clearly defined, facilitating subsequent data reading and identification.

[0147] As an example, and not a limitation, if the total dictionary contains four language types: zh-CN, en, fr, and de, then the table headers will be created as follows: Key, zh-CN, en, fr, de. The system will write the table headers to the first line of the structured table file, forming the header row.

[0148] Step S332: Iterate through all the keys in the set and search for the corresponding translation text in each sub-dictionary of the main dictionary for each key.

[0149] In some embodiments of this application, after writing the header line, the system iterates through all the key names in the set and searches for the corresponding translated text in each sub-dictionary of the main dictionary for each key name.

[0150] Traversal refers to the process of sequentially accessing each key name in the set. Searching refers to the process of retrieving the corresponding translated text from a sub-dictionary based on the key name.

[0151] Specifically, the system retrieves each key name sequentially from the set, and for the current key name, searches for the corresponding translated text in each sub-dictionary of the main dictionary. It's easy to understand that by traversing all the key names in the set and searching for the translated text in each sub-dictionary, the system can obtain the translation content for each key name in each language type.

[0152] By way of example and not limitation, if the set contains key names "HomePage", "Settings", "About", the system processes each key name in turn. For the key name "HomePage", the system looks up the translation text in the corresponding sub-dictionaries for zh-CN, en, fr, and de respectively, and obtains translation contents such as "首页", "Home Page", "Accueil", "Startseite", etc.

[0153] Step S333: If the lookup fails, set the translation text to an empty string.

[0154] In some embodiments of the present application, during the process of looking up the translation text, if the lookup fails, set the translation text to an empty string.

[0155] Here, a failed lookup means that the translation text corresponding to the current key name is not found in the sub-dictionary, which usually occurs when a specific key name is missing in a language entry file.

[0156] Specifically, when the system looks up the translation text corresponding to the current key name in each sub-dictionary, if the current key name does not exist in a certain sub-dictionary, it is determined that the lookup fails, and the system sets the translation text corresponding to this language type to an empty string. It is easy to understand that by setting the translation text of a failed lookup to an empty string, it can be ensured that each key name in the generated structured table file has a corresponding value in each language column, guaranteeing the integrity of the data structure.

[0157] By way of example and not limitation, if the key name "NewFeature" only exists in the sub-dictionaries corresponding to zh-CN and en, but does not exist in the sub-dictionaries corresponding to fr and de, then the system sets the translation text corresponding to this key name to an empty string in the fr and de language columns. In the generated structured table file, the row content corresponding to this key name is: "NewFeature", "新功能", "New Feature", "", "".

[0158] Step S334: Write the key name and the translation texts corresponding to each language type column by column to generate a structured table file.

[0159] In some embodiments of the present application, after completing the lookup of the key name and the translation text, the system writes the key name and the translation texts corresponding to each language type column by column to generate a structured table file.

[0160] Here, writing column by column means the process of writing the key name to the key column and writing the translation texts corresponding to each language type to the corresponding language columns respectively.

[0161] Specifically, for each key name, the system creates a new row, writes the key name into the key column of that row, and sequentially writes the corresponding translation text for each language type into the respective language column of that row. The system repeats the above operation until all key names in the collection have been processed, thus completing the generation of the structured table file. It is easy to understand that by writing the key names and translation text column by column, the data in the total dictionary and collection can be converted into a row and column format of a structured table file.

[0162] As an example, and not a limitation, after processing all the keys, the system generates a structured table file containing a header row and multiple data rows. The header row is "Key, zh-CN, en, fr, de", and the data rows are each key name and its corresponding translated text in each language. The generated structured table file can be saved in formats such as csv and xlsx, making it convenient for developers to view, edit, and manage using spreadsheet tools.

[0163] This embodiment provides a specific implementation of step S330. By creating a table header and writing a header row according to the order of key names and all language types, the meaning of each column in the structured table file is clarified. By traversing all key names in the set and searching for the corresponding translation text in each sub-dictionary of the main dictionary, the translation content of each key name under each language type is obtained. By setting the translation text that fails to be found to an empty string, the integrity of the data structure is ensured. By writing the key names and the translation text corresponding to each language type column by column, the structured table file is generated, thereby completing the generation of the structured table file in the reverse restoration process.

[0164] In some embodiments of this application, the above-described multilingual term management method can be applied to the following scenarios: In some embodiments of this application, a forward conversion mode may be adopted for new project development.

[0165] Specifically, developers first execute step S100 to construct a structured table file as a unified data source for multilingual glossaries, maintaining translation entries for all languages ​​within the structured table file; then, step S200 automatically generates language glossary files for each language from the structured table file. It's easy to understand that through this forward conversion model, developers only need to maintain one structured table file to automatically generate the multilingual glossary files required for the project, reducing maintenance costs.

[0166] As an example, and not a limitation, when developing a Vue project, the forward conversion script in step S200 can be integrated into the Vue project's build process. Specifically, the forward conversion script is embedded in the pre-build process, automatically invoked before the project builds, to automatically generate the latest JSON-formatted language glossary file from the structured table file, thus achieving automatic updates to the language glossary file.

[0167] In some embodiments of this application, a reverse restoration mode can be used for the migration of existing projects.

[0168] Specifically, for older projects with only scattered JSON files, developers first reverse engineer multiple scattered language terminology files into a unified structured table file through step S300; then, they can use the structured table file to perform consistency checks, terminology proofreading, translation progress statistics, and other tasks; finally, the older project is incorporated into a unified management system, and subsequent management and updates of multilingual terms are carried out through the forward conversion mode in step S200.

[0169] It is easy to understand that by using the reverse restoration mode, the scattered multilingual glossary files in the old project can be integrated into a unified structured table file, which facilitates consistency detection and glossary verification, and can be seamlessly connected to the forward conversion mode to achieve efficient management and automated generation of multilingual glossaries.

[0170] As an example, and not a limitation, an old project contains three scattered language entry files: zh-CN.json, en.json, and fr.json. The developers reverse engineered the three files into a single structured table file in XLSX format using step S300. They then used Excel to sort, filter, check for duplicates, and perform statistical analysis on the entries, identifying and correcting missing and inconsistent entries. The project was then incorporated into a unified management system, and subsequent maintenance only required maintaining the structured table file. The updated language entry file was automatically generated using step S200.

[0171] The present invention also provides an electronic device based on the above-described multilingual term management method, the schematic diagram of which is shown below. Figure 5 As shown, the electronic device 100 includes: One or more processors 101, a network interface 102, and a memory 103, Figure 5 The example consists of a processor 101, a network interface 102, and a memory 103.

[0172] The network interface 102 is communicatively connected to the corresponding processor 101, and the processor 101 and the memory 103 can be connected via a bus or other means. Figure 5 Taking the example of a connection between China and Israel via a bus.

[0173] The network interface 102 is used to establish communication connections between the processor 101 and other external devices, including the following types: RJ-45 interface, SC fiber optic interface, AUI interface, FDDI interface and Console interface.

[0174] The memory 103, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. The processor 101 executes various functional applications and data processing of the electronic device by running the non-volatile software programs, instructions, and units stored in the memory 103, thereby implementing the multilingual term management method of the above-described method embodiments.

[0175] The memory 103 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 103 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 103 may optionally include memory remotely located relative to the processor 101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0176] The one or more units are stored in the memory 103, and when executed by one or more processors 101, they execute the multilingual term management method in any of the above method embodiments.

[0177] The aforementioned electronic device can execute the multilingual term management method provided in the embodiments of the present invention, and has the corresponding program modules and beneficial effects for executing the method. Technical details not described in detail in the electronic device embodiments can be found in the multilingual term management method provided in the embodiments of the present invention.

[0178] This invention also provides a non-volatile computer-readable storage medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The non-volatile computer-readable storage medium carries one or more programs, which, when executed, implement the multilingual term management method of this disclosure.

[0179] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above. For the sake of brevity, they are not provided in detail; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for managing multilingual glossary entries, characterized in that, include: A structured table file is constructed as a unified data source for multilingual entries. The structured table file includes a key column and multiple language columns. The key column is used to store the unique key name of the entry, and the language columns are used to store the translated text of each language corresponding to the key name. Read the structured table file, parse and identify the language type corresponding to each language column, construct a mapping relationship between key names and translated text for each language type, and generate the corresponding language entry file based on the mapping relationship; Read multiple language terminology files, identify the language type corresponding to each language terminology file, extract and merge the mapping relationship between key names and translated text in each language terminology file, and generate the structured table file.

2. The method according to claim 1, characterized in that, The steps of reading the structured table file, parsing and identifying the language type corresponding to each language column, constructing a mapping relationship between key names and translated text for each language type, and generating the corresponding language entry file based on the mapping relationship further include: Read the structured table file and create a corresponding dictionary for each language type; Verify the content format of the structured table file, parse the table header, and identify each language column; The structured table file is read line by line, data validation and processing are performed on each line, and the key name and translated text are written into the corresponding dictionary; Generate corresponding language entry files based on the contents of each dictionary.

3. The method according to claim 2, characterized in that, The step of reading the structured table file line by line and performing data validation and processing on each line further includes: Determine if the current line is a reserved line; if so, skip the current line. Check if the key name in the current row is duplicated. If it is duplicated, log the information and skip the current row. The key name is generated according to preset rules; the preset rules include ID encoding, naming prefix or naming suffix.

4. The method according to claim 2, characterized in that, The steps prior to writing the key names and translated text into the corresponding dictionary also include: The translated text is cleaned; the cleansing process includes at least one of removing spaces, removing redundant line breaks, and removing special characters. Determine whether the translated text is missing; if it is missing, set the translated text to an empty string.

5. The method according to claim 1, characterized in that, The step of reading multiple language terminology files, identifying the language type corresponding to each language terminology file, extracting and merging the mapping relationship between key names and translated text in each language terminology file, and generating the structured table file further includes: Create a master dictionary and a set to record all key names; Read each language entry file one by one, verify the content format, identify the language type according to the file name, and store the key-value content of each language entry file into the total dictionary, and merge the key names into the set; The structured table file is generated based on the general dictionary and the set.

6. The method according to claim 5, characterized in that, The step of generating the structured table file based on the total dictionary and the set includes: Create the table header and write the header row according to the key name and all language types in order; Iterate through all the keys in the set, and for each key, find the corresponding translated text in each sub-dictionary of the main dictionary; If the search fails, the translated text will be set to an empty string; Write the key names and the corresponding translation text for each language type into columns to generate the structured table file.

7. The method according to claim 1, characterized in that, Also includes: Generate a log file; the log file is used to record at least one of the following: execution process, skipped line information, exception information, and inconsistency information; For key names where the translation text is empty, the corresponding translation text is automatically generated, and the automatically generated translation text is marked.

8. The method according to any one of claims 1-7, characterized in that, The construction of structured table files as a unified data source for multilingual entries includes: Configure the file format of the structured table file; the file format includes csv, xlsx, XML, YAML, or PO format; Configure the key columns and multiple language columns of the structured table file; and configure extended columns as needed, which are used to store the remarks information corresponding to the key names.

9. An electronic device, characterized in that, include: At least one processor; At least one network interface, which is communicatively connected to a corresponding processor; as well as, A memory communicatively connected to the at least one processor; wherein, The network interface is used to establish communication connections between the processor and other external devices; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the multilingual term management method as described in any one of claims 1-8.

10. A non-volatile computer storage medium, characterized in that, The computer storage medium stores computer-executable instructions, which are executed by one or more processors, causing the one or more processors to perform the multilingual term management method as described in any one of claims 1-8.

Images