Patent Grant
10599782
The present disclosure relates to translation supply chains, and more specifically, to analytical methods of identifying segments that do not require further review during translation processes.
Translation workflows can be used to provide high quality fluent language translations. In some workflows, source text is processed by a series of components, which may be located on a single device or across multiple devices. A translation supply chain (TSC) typically involves a series of operations beginning with a text in a source language, and ending with a translated text in a target language. Often, TSCs utilize a combination of machine translations and human editing. In many TSCs, source text is delineated into segments which are translated individually. These translations may be based on a repository of previous translations, via a machine translation model, or a combination of both. In existing systems, human editors must then review many or all of these segments in order to verify their accuracy, and correct any translation errors manually. This post-edit process is time consuming and expensive, but is required by existing systems to ensure a high quality translation.
According to one embodiment of the present disclosure, a method for processing text in an optimized translation workflow is provided. The method includes receiving a first segment of text in a first language to be translated into a second language. The first segment of text is evaluated using a pattern model to generate a first s-score, by operation of one or more processors. Additionally, a second segment of text in the second language is generated based on processing the first segment of text using a machine translation model. Upon determining that the first s-score exceeds a predefined threshold, the method includes flagging the first segment of text for auto-substitution with the second segment of text, such that the first segment of text is not reviewed by a human editor.
According to a second embodiment of the present disclosure, a system including one or more computer processors and a memory containing a program is provided. The program, when executed by the one or more computer processors performs an operation for processing text in an optimized translation workflow. The operation includes receiving a first segment of text in a first language to be translated into a second language. The first segment of text is evaluated using a pattern model to generate a first s-score. Additionally, a second segment of text in the second language is generated based on processing the first segment of text using a machine translation model. Upon determining that the first s-score exceeds a predefined threshold, the operation includes flagging the first segment of text for auto-substitution with the second segment of text, such that the first segment of text is not reviewed by a human editor.
According to one embodiment of the present disclosure, a computer program product is provided. The computer program product includes a computer-readable storage medium having computer-readable program code embodied therewith, the computer-readable program code executable by one or more computer processors to perform an operation for processing text in an optimized translation workflow. The operation includes receiving a first segment of text in a first language to be translated into a second language. The first segment of text is evaluated using a pattern model to generate a first s-score. Additionally, a second segment of text in the second language is generated based on processing the first segment of text using a machine translation model. Upon determining that the first s-score exceeds a predefined threshold, the operation includes flagging the first segment of text for auto-substitution with the second segment of text, such that the first segment of text is not reviewed by a human editor.
In embodiments of the present disclosure, text in a source language may be provided to a TSC (e.g., by a client) for translation into one or more target languages. For example, a client may provide technical specifications or instructions to be translated to any number of languages. In an embodiment, the source text is split into a number of segments based on a variety of factors, such as linguistic markers, punctuation, grammar, and other methodologies. These segments may be of any length. In embodiments, the “size” of a segment is an integer referring to its length (e.g., by number of words) while the “scope” of a segment is a classification based on the size (e.g., small, medium or large). In one embodiment, a segment that is four words or fewer is “small” scope, “medium” scope refers to segments between five and fourteen words, and segments fifteen words or longer are “large” scope. Of course, in various embodiments, these delineations may differ based on the particular implementation. Additionally, in some embodiments, there may be any number of scopes, in addition to or instead of the three discussed above. As used herein, the “scope” refers to the scope of the source segment in the original language, as opposed to the scope or size of the subsequent translation. Further, references to a “segment” are intended as references to a source segment, unless otherwise indicated.
In embodiments of the present disclosure, segments may be compared against a repository of prior translations in order to determine whether a match exists. For example, if a particular segment is found in the repository, the corresponding translation can be utilized to help reduce or eliminate further downstream processing of the segment. In some embodiments, segments are processed to determine a “match type” for each segment, which refers to how closely the segment matches an entry in the repository. In one embodiment, one such match type is an “automatic,” “auto substitution,” or “auto exact” match type. An AutoSub match indicates that the exact segment is found in the repository, with identical context. For example, the context is identical if the source and destination languages are identical, the domain matches, the project and document ID match, and the like. In one embodiment, segments with an AutoSub match may be flagged as not requiring any further downstream editing, because a human has already reviewed the translation in the repository. In some embodiments, AutoSub matches may still receive some level of proofreading, but the intensive and expensive post edit may be bypassed.
In one embodiment, a second match type may be an “exact” match. An exact match may be identified for a segment where the segment's content is found in the repository (i.e., the segment exactly matches an entry in the repository), but the context differs. Additionally, in one embodiment, a segment may have a “fuzzy” match. A fuzzy match may refer to a segment which is close to or is related to a segment in the repository, but not exactly matched. For example, in one embodiment, the segment “hard drive” may be considered to be a fuzzy match for “HDD,” “database,” and other related words. Similarly, in an embodiment, a segment that includes “the fox jumped over the fence” may be a fuzzy match with a segment that includes “the fox leaped over the fence,” “the fox jumps over the fence,” “the dog is jumping over the fence,” and the like. In some embodiments, in addition to providing match types, the system may also provide a confidence measure indicating how close the match is.
In one embodiment, if no match is found in the repository (either auto-exact, exact, or fuzzy), the segment may be processed with a machine translation model, which may be trained and refined using machine learning (e.g., using final translations after a human has reviewed the segments during post edit). In an embodiment, after being processed by the machine translation model, the segment is marked as having a “machine” or “machine translation” match type. In some embodiments, segments may be organized based on the class they belong to. In an embodiment, the segment class refers to the scope and match type of the segment. For example, a first class may be “small” scope and “machine translation” match, while a second class includes “medium” scope and “exact” match segments, and so forth. Of course, any combination of scope and match type may constitute a class. In some embodiments, once a segment has been processed, it is provided to a human for post edit in order to verify its accuracy. Embodiments of the present disclosure enable the analysis of segments based in part on their class in order to identify segments that need not be subjected to further review, or require only a reduced level of review, and can therefore bypass this downstream post edit process.
Although illustrated as a single device, in some embodiments, the Segment Analytics Device 105 may be implemented as components on various distinct computing devices, in various physical or geographic locations. As illustrated, the Memory 115 includes a Smart Edit Application 130, which includes a Checker Component 135, a Mapper Component 140, and a Reviewer Component 145. In the illustrated embodiment, the Storage 120 includes a Linguistic Asset Store 150 and Linguistic Analytics 155. Although illustrated as residing in Storage 120 on the Segment Analytics Device 105, in various embodiments, one or both of the Linguistic Asset Store 150 and Linguistic Analytics may reside on one or more other devices, such as a remote database system or a cloud storage environment. As illustrated, the Linguistic Asset Store 120 includes a Translation Memory 160, a Dictionary 165, and Regional Assets 170. Although a single Translation Memory 160 and Dictionary 165 are shown for illustrative purposes, in embodiments, there may be any number of these components.
In an embodiment, the Translation Memory 160 includes a repository of prior translations that may be useful for current translation efforts. For example, as discussed above, the Translation Memory 160 may include a number of source segments and the corresponding final translations. In some embodiments, the Translation Memory 160 may be domain-specific. For example, translations associated with a healthcare domain may be maintained in a separate Translation Memory 160 than translations relating to law or technology. In some embodiments each domain is stored within a single Translation Memory 160, along with data or metadata indicating the domain to which each entry belongs. Additionally, in some embodiments, the Translation Memory 160 is language-specific with respect to the source language, the target language, or both. For example, in one embodiment, a first Translation Memory 160 may include translations from English to French, while a second Translation Memory 160 includes translations from English to Spanish. In some embodiments, however, each source/destination language pair may be included in one or more Translation Memories 160, with accompanying data to indicate the source and target languages. Additionally, in some embodiments, the Translation Memory 160 may be distributed across multiple computing systems. In an embodiment, the Translation Memory 160 includes records of a large number of prior translations, including records that are unrelated to the current translation effort.
In some embodiments, each entry in the Translation Memory 160 also includes an indication of the context of the historical segment. For example, the entry may include information about the project or document the segment originated in, an indication of one or more surrounding segments, and the like. In one embodiment, each entry in the Translation Memory 160 may include other linguistic markers that indicate syntax, punctuation, linguistic analysis, and the like. In the illustrated embodiment, the Dictionary 165 includes predefined translations for individual words or small phrases or terms. In some embodiments, there may be multiple Dictionaries 165, each domain-specific. In some embodiments, the presence of a refined and domain-specific Dictionary 165 may help facilitate high quality translations without the need for additional processing by a machine translation model, and without further review by human editors. In an embodiment, the Regional Assets 170 correspond to one or more corpuses that are specialized in a particular language, dialect, culture, and domain of particular geographic regions. In embodiments, the use of Regional Assets 170 may improve translations targeted towards or originating from regions represented by the Regional Assets 170. In some embodiments, the Dictionary 165 and Regional Assets 170 may be distributed across multiple devices.
As illustrated, the Linguistic Analytics 155 includes Edit Logs 175 and Pattern Models 180. In an embodiment, the Edit Logs 175 include data about segments which have been previously translated. For example, in an embodiment, each Edit Log 175 may include the source segment, the initial translation provided by the system, and the final translation accepted by a human reviewer. In one embodiment, each Edit Log 175 may also include an indication of the associated domain and languages. In some embodiments, each Edit Log 175 also includes the context of the segment, such as the surrounding segments. Similarly, in an embodiment, each Edit Log 175 includes an indication as to the machine translation model that was used (if any) to generate the translation. In some embodiments, each Edit Log 175 includes an indication as to how long the human editor spent reviewing or revising the translation. In one embodiment, each Edit Log 175 may also include other linguistic markers that indicate syntax, punctuation, linguistic analysis, and the like. Similarly to the Translation Memory 160, in an embodiment, the Edit Logs 175 include data about prior translations which are unrelated to the current translation efforts.
In the illustrated embodiment, the Pattern Models 180 are generated based on the Edit Logs 175, and are generally used to identify excellent matches, such that no further processing or review is required (or such that reduced review is needed). In some embodiments, each Pattern Model 180 may correspond to a particular domain and language pair. In some embodiments, there may be multiple Pattern Models 180 within a domain and language pair. For example, if multiple machine translation models are available, or multiple Translation Memories 160 or Dictionaries 165 can be used, a different Pattern Model 180 may be generated corresponding to each of these options. In various embodiments, the Pattern Models 180 may be rules-based, or may be generated based on analytical modeling techniques, as will be discussed in more detail below.
In one embodiment, the Checker Component 135 is invoked prior to machine translation to perform size analysis on source segments based on the Pattern Models 180. For example, in one embodiment, the Checker Component 135 is utilized after the source segments have been processed to identify matches in the Translation Memory 160. The Checker Component 135 may analyze these segments, along with any linguistic markers that have been included, in order to identify excellent matches, as will be discussed in more detail below. In one embodiment, the Checker Component 135 focuses on specific small segments (e.g., one to two words in length) where the terminology is well-defined for the particular domain. In such an embodiment, the Pattern Model 180 may define rules for translating small segments based on the associated domain Dictionary 165. In some embodiments, the Checker Component 135 only reviews segments which have no match (i.e., a match type of “no match”) that may be processed via the machine translation model(s) to generate a machine match.
In an embodiment, the Mapper Component 140 generates the Pattern Models 180. For example, for a given domain, the Mapper Component 140 may retrieve Edit Logs 175 corresponding to the domain and associated with a particular machine translation model. In some embodiments, the Mapper Component 140 may then build a map table containing metadata for assessing quality across all segments having machine translation matches. For example, in one embodiment, each row in the map table may include the machine translation match, the final translation, the scope of the source segment, an edit score of the segment/Edit Log 175, and other linguistic markers. In an embodiment, the edit score is defined based in part on the edit distance (e.g., the Levenshtein distance) between the machine translation and the final translation, as well as the determined linguistic noise associated with the segment, as will be discussed in more detail below. In an embodiment, each Pattern Model 180 is used to generate s-scores for source segments of text. As used herein, an s-score refers to the suitability of the corresponding segment for automated translation, such that no human review is required (or reduced review is required). That is, in an embodiment, the s-score is used to determine whether the segment can be automatically translated with a Dictionary 165 or machine translation model, without the need for full post-edit review.
The Mapper Component 140 may then utilize the map table to generate a Pattern Model 180. In one embodiment, the Pattern Models 180 may include a rules-based table. For example, in one embodiment, the Pattern Models 180 may determine an s-score for a new segment based on identifying a row in the Pattern Model 180 table matching the associated domain, machine translation model, size of the segment, scope of the segment, aggregate edit score of segments with the same scope, and the like. In some embodiments, the Mapper Component 140 may generate predictive models for the Pattern Models 180 by applying analytical modeling techniques against the map table. In some embodiments, a portion of the Edit Logs 175 may be set aside as validation data while the remaining are used as training data. In various embodiments, a number of modeling algorithms may be used, including logistic regression, linear discriminant analysis, k-nearest neighbors, classification and regression trees, Gaussian naïve Bayes, support vector machines, and the like. In some embodiments, multiple models may be created, and the validation data may be used to identify the most accurate model for the particular domain, machine translation model, and scope.
In the illustrated embodiment, the Reviewer Component 145 is utilized to process segments after they have been processed via a machine translation model. Similarly to the Checker Component 135, the Reviewer Component 145 may utilize the Pattern Models 180 to analyze each segment and identify segments that are excellent, and need no further processing (or reduced downstream processing). In some embodiments, the Reviewer Component 145 may apply the same Pattern Model 180 as the Checker Component 135. In other embodiments, the Pattern Models 180 differ based on the stage in the TSC that the segment is in (e.g., before or after machine translation). In some embodiments, the Reviewer Component 145 may utilize a different threshold than the Checker Component 135 when determining which segments should be marked as “excellent” matches. In one embodiment, the Checker Component 135 only applies Pattern Models 180 to segments below a predefined size or scope, while the Reviewer Component 145 applies Pattern Models 180 to additional segments.
As illustrated, Content 215 is transmitted to block 220, where linguistic optimization is undertaken. In an embodiment, linguistic optimization involves dividing the Content 215 into segments, and attempting to find a match in the Translation Memory 160 for each segment. This dividing process may be accomplished based on a variety of factors, such as linguistic markers associated with the Content 215, punctuation, syntax, grammar, and the like. In an embodiment, once the segments have been created, the Translation Memory 160 is searched for previous high-quality translations that match each segment. As discussed above, in an embodiment, these matches may include “auto” matches, “exact” matches, “fuzzy” matches, and “no match.” In some embodiments, linguistic markers may be inserted into the segments during linguistic optimization, in order to facilitate downstream processing.
In an embodiment, the “no match” segments are then forwarded to block 230 for machine translation. This component may include one or more machine translation models, which can be trained and refined during use. In some embodiments, each of the segments (including all match types) are then transmitted to block 235 for post editing. In embodiments, some or all of the segments are first processed by a Checker Component 135 prior to being sent to block 230. During post editing, human editors can review and revise the translations provided during linguistic optimization and machine translation, in order to ensure fluent results. In embodiments, some or all of the machine translated segments may be analyzed by the Reviewer Component 145 prior to post editing, and some segments may be marked as “excellent” in order to bypass post editing. Finally, based on this post-editing process, the Final Translation 240 is generated. As will be discussed below in more detail, the Smart Edit System 210 is integrated at various points into the TSC 205 to improve this process.
After processing by the Checker 135, the “no-match” segments are processed using one or more machine translation models, as illustrated in block 230, to create an initial translation for each segment that does not already have a match (or have not been marked as “excellent” by the Checker 135). Next, the Reviewer Component 145 analyzes each segment using the Pattern Models 180 to identify excellent matches. In some embodiments, different Pattern Models 180 than the ones used by the Checker 135 may be utilized to make this determination. In some embodiments, a different predefined threshold is used at this stage. In one embodiment, segments with match type “excellent” then bypass the post editing block at 235, and proceed straight to proofreading, or to the Final Translation 240 with no additional downstream processing. In some embodiments, excellent matches are forwarded to a “light” post edit process for a brief review. In one embodiment, this light post-edit process may be performed by a human. In other embodiments, the light post edit is an automated process as well. In an embodiment using light post editing, all segments with match type of “excellent” are reviewed to ensure that the translations are sufficiently accurate. If so, no further processing is required and the segment is flagged as “final” or “auto substitution.” If not, in one embodiment, the segment is forwarded on for full post editing in block 235.
During the post editing block 235, a skilled human reviewer must analyze each of the segments other than “auto exact” matches, to ensure quality translation. This post-edit is significantly more skill and resource intensive than light post editing, and the cost per segment is significantly higher. During post editing, the human reviewer can either accept the proposed translation (e.g., a match from the Translation Memory 160 or a machine translation), modify the translation, or reject it and create a new translation. In embodiments disclosed herein, the segments marked as “excellent” based on the Pattern Model 180 may bypass this post edit process, thereby reducing resource requirements and improving the efficiency of the TSC. Additionally, as illustrated, the Mapper Component 140 interacts with the Linguistic Analytics 155 to retrieve Edit Logs 175 and generate Pattern Models 180. Although not illustrated, in some embodiments, the segments are transferred between each component by storing them in a centralized location. For example, in one embodiment, the Content 215 is initially stored in the Linguistic Asset Store 150, until it is retrieved for linguistic optimization. After the segments have been created and matches identified, each segment may then be stored back in the Linguistic Asset Store 150, where the Checker Component 135 retrieves them. Any excellent matches may be flagged or marked as “excellent,” and then returned to the Linguistic Asset Store 150. In this way, each component can access the segments for processing.
In some embodiments, the Final Translations 240 are also used in several ways, in addition to being sent to the client. For example, in one embodiment, the Final Translations 240 are transmitted to the Linguistic Asset Store 150 for inclusion in the Translation Memory 160. In some embodiments, the Final Translations 240 are also transmitted to the Linguistic Analytics 155 for inclusion in the Edit Logs 175. In some embodiments, the actual edits and changes made by the human reviewer during post edit are also included within the Edit Logs 175. In one embodiment, the length of time that the human reviewer spent on the segment is included within the Edit Log 175. Additionally, in some embodiments, the results of the post editing process are used to refine the machine translation models and/or the linguistic optimization process. In this way, the system 300 can learn and gain increased maturity during use.
During Machine Translation 230, the segments of match type No Match 430 are processed with one or more machine translation models, and converted into Machine matches 435. Next, the Reviewer Component 145 reviews the segments with match type of Machine 435. Depending on the specific Pattern Model 180, these may either remain Machine 435, be changed to Excellent 440, or be changed to AutoExact 415 or Final 445. Although not illustrated, in some embodiments, the Reviewer Component 145 may similarly process Exact 420 and Fuzzy 425 segments as well. In the illustrated embodiment, the segments proceed to a Light Post Edit 402. As illustrated, during Light Post Edit 402, segments may be left with the same match type, or may be flagged as “Excellent,” “Final,” or “AutoExact” in various embodiments. In one embodiment, Light Post Edit 402 involves a brief scan (which may be automated or human) for major errors or issues, without concern for minor issues. In another embodiment, Light Post Edit 402 involves searching for specific patterns, such as markup tags indicating text formatting, to ensure that these formatting issues are corrected. In one embodiment, Light Post Edit 402 simply involves identifying and marking faults or issues, without spending time to correct them. Additionally, in some embodiments, Light Post Edit 402 is not used, and segments marked as “excellent” matches may bypass all downstream processing, while matches that are neither “excellent” nor “auto-exact” are subject to post-editing.
At block 235, post editing is completed. As discussed above, during post edit, the translations are finalized such that all segments are moved to match type of Final 445. In the illustrated embodiment, some Excellent matches 440 are also processed in post edit. In some embodiments, however, segments with match type Excellent 440 are not sent to post edit at all, and proceed straight to proofreading or to final. Finally, in block 405, a final proofreading is completed. In some embodiments, however, post edit is the final block. As illustrated, the Checker Component 135 and Reviewer Component 145 can identify Excellent 440 match types, which can be flagged for reduced downstream processing or for no downstream processing at all. This significantly reduces the costs involved in the TSC 400.
In embodiments of the present disclosure, the segments are processed based in part on their size, scope, and match type. Additionally, in an embodiment, the Pattern Models 180 are generated based in part on edit scores for each Edit Log 175. In one embodiment, each edit score is determined based at least in part on a linguistic noise of the corresponding segment, as will be discussed in more detail below. Further, in some embodiments, in order to determine the linguistic noise of a segment, a linguistic vector for the corresponding segment must first be generated, as will be discussed in more detail below. Additionally, in some embodiments, the maturity of each machine translation model is tracked over time based at least in part on the linguistic noise and linguistic vectors, as will be discussed in more detail below.
In the illustrated graphs 500A-C, a linguistic coordinate has been generated and graphed on a 2-dimensional coordinate plane for each class of segments. For example, each diamond shape 510A-C represents a linguistic coordinate for segments with match type “exact,” while the squares 515A-C represent “fuzzy” matches and the triangles 520A-C represent machine translations. Further, as illustrated, each Graph 500A-C includes a theoretical “perfect point” at (1.0, 0), as will be explained further below. Additionally, as illustrated, each linguistic coordinate 510A-C, 515A-C, and 520A-C has a corresponding linguistic vector, which represents a measurement of linguistic noise across the relevant dimensions. Although
In the illustrated embodiment, each linguistic coordinate 510A-C, 515A-C, and 520A-C is based on the weighted efficiency and accuracy of the corresponding class of segments. In an embodiment, the linguistic coordinates are generated based on the Edit Logs 175. In this way, the linguistic vector for each class of segments may be determined based on a large number of entries, which may be unrelated to the current translations. The accuracy of a class of segments refers to the percentage of segments in the class that are accepted without change during post edit. For example, in an embodiment, the Mapper Component 140 may retrieve and parse Edit Logs 175 to determine, for each Edit Log 175, the class of the segment (i.e., the scope and match type), and whether the proposed translation was accepted without change, or modified/rejected. Subsequently, the Mapper Component 140 can compute the accuracy (also referred to as post edit leverage) for each class of segments. Generally, a higher accuracy or leverage indicates a more mature system, and reduced effort and costs.
As illustrated, the linguistic coordinates 510A-C, 515A-C, and 520A-C are also based on the weighted efficiency (also referred to as post edit factor) of each class. In an embodiment, the weighted efficiency is a weighted measurement of productivity during the post edit process. In one embodiment, the weighted efficiency is measured in terms of the productivity of a human editor processing segments of the indicated class, weighted by the editor's productivity when processing segments of the same scope, with match type “no match.” In one embodiment, the productivity is measured in terms of the number of words per second that the editor processes. For example, suppose, based on the Edit Logs 175, the Mapper Component 140 determines that during the post edit process, segments of scope “small” and match “no match” are reviewed at two words per second. Suppose further that, as reflected in the Edit Logs 175, segments of scope “small” and match type “exact” are processed at an average speed of ten words per second. In such an embodiment, the efficiency of the class “small” and “exact” is ten words per second, and the weighted efficiency is ten words per second weighted by the two words per second for “no match” segments. In one embodiment, this weighted efficiency is given by Formula 1 below, where WeightedEfficiencySM is the weighted efficiency of segments with scope “S” and match type “M”:
In Formula 1, SpeedSNo Match represents the average efficiency of post editors when processing segments of match type “no match” and scope “S” (e.g., two words per second). Similarly, SpeedSM represents the average efficiency of post edit when reviewing segments with match type “M” and scope “S” (e.g., ten words per second). In an embodiment, each of SpeedSNo Match and SpeedSM are determined based on analyzing a plurality of Edit Logs 175. As illustrated in graphs 500A-C, a theoretical perfect match point (indicated by the circles 505A-C) is located at (1.0, 0). That is, the perfect match point indicates a hypothetical segment class that is never rejected during post edit (e.g., accepted 100% of the time) and is processed at a theoretically infinite efficiency (e.g., with no human review at all).
In the illustrated embodiment, the Mapper Component 140 can generate a linguistic vector for each class of segments. In an embodiment, the linguistic vector for a class is based on the distance between the class's linguistic coordinate 510A-C, 515A-C, and 520A-C, and the theoretical perfect point 505A-C for the class, as illustrated in Formula 2, below. In embodiments, because the linguistic vector represents the noise of each class of segments, a smaller linguistic vector indicates a more mature system and better quality translations. As illustrated, in each graph 500A-C (i.e., for each scope), the linguistic vector for exact matches, represented by VectorE, is smaller than the linguistic vector for fuzzy matches (VectorF), while the largest vector represents machine matches (VectorM). Thus, as depicted, exact matches tend to be less noisy than fuzzy matches, while machine translations tend to include the most linguistic noise (other than segments with no match, which of course have a weighted efficiency of 1.0 and an accuracy of zero). As used herein, ClassSM represents the class of segments with scope “S” and match type “M.” In Formula 2, LinguisticVectorSM represents the linguistic vector for ClassSM. Similarly, LingusticCoordinateSM is the linguistic coordinate for ClassSM and PerfectMatch refers to the linguistic coordinate for the theoretical perfect match point.
LinguisticVectorSM=Distance(LingusticCoordinateSM,PerfectMatch) Formula 2
Similarly, as illustrated, the linguistic vectors for each class tends to be smaller as scope decreases. That is, the linguistic vector for point 510A, which represents segments in the class associated with “large” scope and “exact” match (e.g., Classlargeexact) is larger than the corresponding linguistic vector for Classmediumexact (from point 510B), which is larger than the linguistic vector for Classsmallexact (illustrated by point 510C). Thus, as depicted, within each match type, smaller segments tend to have less linguistic noise than larger segments. Further, in embodiments, smaller segments tend to include less linguistic noise per word than larger segments. That is, smaller segments do not simply include less linguistic noise because they include fewer words. Instead, the average noise per word also tends to be lower, as will be discussed in more detail below.
At block 625, the Mapper Component 140 computes the edit speed for “no-match” segments within each scope. That is, the Mapper Component 140 determines the average speed with which segments with no match and scope “small” (Classsmallno match) are processed during post edit, as well as the average speed with which segments in Classmediumno match are processed and the average speed with which segments in Classlargeno match are processed. In an embodiment, this is accomplished by determining, for each no-match segment, the number of seconds that were spent reviewing the segment divided by the number of words in the segment. These results are then averaged within each scope. In other embodiments, this is accomplished by, for each no-match segment, determining the number of words in the segment divided by the number of seconds spent reviewing the segment. In this way, the baseline efficiency is determined which can be used to weight the efficiency of other match types.
At block 630, the Mapper Component 140 selects a segment class. The method 600 then proceeds to block 635, where the Mapper Component 140 computes class efficiency and accuracy. That is, as discussed above, the Mapper Component 140 may parse each Edit Log 175 associated with the selected class to determine the efficiency or speed for each Edit Log 175 and whether it was accepted. These results can then be aggregated (e.g., averaged) to determine the class efficiency and accuracy. The method 600 then proceeds to block 640, where the Mapper Component 140 determines the class linguistic vector for the selected class. As discussed above, the linguistic vector may be the distance between a class linguistic coordinate (defined based at least in part on the weighted efficiency and accuracy of the class) and a theoretical perfect match point. At block 645, it is determined whether there are additional classes yet to be processed. If so, the method 600 returns to block 630. If not, the method 600 terminates at block 650. In this way, a linguistic vector can be generated for each segment class based on data from historical Edit Logs 175. In some embodiments, linguistic vectors are generated only for Edit Logs 175 associated with a “machine” match, rather than all match types.
In some embodiments, rather than utilizing the number of words for the selected match type (WordsM), the Mapper Component 140 utilizes the sum of all words across all match types and segments. The method 700 then proceeds to block 735, where the Mapper Component 140 determines whether there are additional classes remaining to be processed (e.g., that do not yet have a calculated linguistic noise). If so, the method 700 returns to block 710. Otherwise, the method 700 terminates at block 740.
The method 800 continues to block 820, where the Mapper Component 140 determines the size of the selected segment. As above, this may be determined based on a tag or marker that was previously associated with the segment. At block 825, the Mapper Component 140 determines the number of words in all Edit Logs 175 included in the class of the selected segment. That is, if the segment is in ClassSM, the Mapper Component 140 determines WordsSM. The method 800 then proceeds to block 830, where the Mapper Component 140 determines the weight of the selected segment. In an embodiment, the weight of the particular segment “i” is based on the size of the segment as compared to the size of the segment class. In one embodiment, the segment weight of the ith segment is defined as SegmentWeight(i). If segment “i” is in ClassSM, the SegmentWeight(i) is defined according to Formula 4, below:
Once the segment weight has been determined, the method 800 proceeds to block 835, where the Mapper Component 140 determines the linguistic noise for the class of the selected segment. This may be accomplished as discussed above with reference to
LinguisticNoise(i)=LinguisticNoiseSM*SegmentWeight(i) Formula 5
In this way, the linguistic noise of a particular source segment in an Edit Log 175 can be determined, based in part on the linguistic noise of the class to which the segment belongs (which is further based in part on the linguistic vector associated with the class). In one embodiment, the linguistic noise of each particular segment is utilized when determining the quality of translations, as will be discussed in more detail below. Additionally, in an embodiment, the linguistic noise of each segment is used to generate Pattern Models 180, as will be discussed in more detail below. After computing the linguistic noise for the particular selected segment, the method 800 proceeds to block 845 where the Mapper Component 140 determines whether there are additional segments (e.g., additional Edit Logs 175) to be processed. If so, the method 800 returns to block 810. If not (e.g., all of the Edit Logs 175 now have a calculated linguistic noise), the method 800 terminates at block 850.
Notably, the method 900 does not require calculation of the class linguistic noise, but instead is calculated directly based on the class linguistic vector. Once the segment's linguistic noise is computed, the Mapper Component 140 determines whether there are additional segments (e.g., additional Edit Logs 175) that remain to be processed. If so, the method 900 returns to block 910 to select another segment. If not, the method 900 terminates at block 945.
The method 1000 then proceeds to block 1020, where the Mapper Component 140 determines the linguistic noise of the source segment of the selected Edit Log 175. This may be accomplished based on method 800 or method 900 above, or Formula 5 or 6. The method 1000 continues to block 1025, where the Mapper Component 140 computes the edit score of the Edit Log 175. In one embodiment, the edit score of an edit log “i” is given by EditScore(i), and is defined according to Formula 7 below, where the edit distance of the ith segment is given by EditDistance(i):
EditScore(i)=LinguisticNoise(i)*EditDistance(i) Formula 7
The method 1000 then proceeds to block 1030, where the Mapper Component 140 determines whether there are additional Edit Logs 175 to process. If so, the method 1000 returns to block 1010 to select an Edit Log 175. If not, the method 1000 proceeds to block 1035, where the Mapper Component 140 computes aggregate edit score(s). For example, in one embodiment, the Mapper Component 140 computes the sum of the edit scores of each Edit Log 175 associated with each class in order to generate an aggregate edit score for each class. In various embodiments, the aggregate edit score may be based on the mean, average, or median edit score of the appropriate Edit Logs 175. As discussed above, in some embodiments, edit scores are only generated for segments with match type corresponding to machine translation. In such an embodiment, a single aggregate edit score may be generated based on the determined edit scores for all Edit Logs 175 with match type corresponding to machine translation. In some embodiments, the Mapper Component 140 generates an aggregate edit score for each scope, for one or more match types. In one embodiment, the Mapper Component 140 generates an aggregate edit score for each scope of segment, based on Edit Logs 175 associated with machine translation matches. For example, if three scopes are used (small, medium, and large), the Mapper Component 140 may generate a scope edit score for small segments that used machine translation, a scope edit score for medium segments that used machine translation, and a scope edit score for large segments that used machine translation.
In an embodiment, the aggregate edit score of a particular scope or class can be used to assess the quality of translations for the corresponding scope or class. For example, a higher aggregate edit score indicates increased noise and edit distance, while a lower aggregate edit score indicates a lower linguistic noise. In some embodiments, when new segments are received, they are not eligible for conversion to “excellent” match unless the aggregate edit score for the corresponding scope exceeds a predefined threshold. That is, in one embodiment, when a new segment is processed by the Checker Component 135 and Reviewer Component 145, the Checker Component 135 and Reviewer Component 145 first determine whether the aggregate edit score for the corresponding scope exceeds a predefined threshold. If so, the Checker Component 135 and Reviewer Component 145 may proceed to process the segment with the appropriate Pattern Model 180. If the aggregate edit score does not exceed the threshold, the Checker Component 135 and Reviewer Component 145 may determine that segments of the corresponding scope are not an excellent match, even without applying the Pattern Model 180.
In the illustrated embodiment, the Machine Translation Model ID 1110 refers to the particular machine translation model that was used to generate the translation. In some embodiment, as discussed above, Pattern Model(s) 180 are only generated for use with new segments that are to be processed (or have been processed) with machine translation. The Segment Size 1115 refers to the number of words in the source segment of the Edit Log 175, and the Segment Scope 1120 refers to the source segment scope. The Edit Score 1125 may be determined for the Edit Log 175, as discussed above. Finally, Other Linguistic Markers 1130 can include any other linguistic markers that may be useful to building a more accurate model, such as markers or tags relating to punctuation, syntax, grammar, formatting (e.g., bold, italics), and the like. In some embodiments, the Other Linguistic Markers 1130 include tags indicating patterns or attributes of the content, such as whether a word is masculine or feminine, or singular or plural. In an embodiment, these linguistic markers are inserted during the linguistic optimization processing or by the Checker Component 140. In one embodiment, the Mapper Component 140 generates a map table based on the Edit Logs 175, and builds the Pattern Model(s) 180 based on the map table. In an embodiment, the map table may include the final translation, initial translation (e.g., machine translation), scope and size of the source segment, edit score, other linguistic markers, and the like.
In an embodiment, when new segments are to be processed via a Pattern Model 180, one or more variables can be identified and used. For example, in one embodiment, the Smart Edit Application 130 may determine the Domain ID 1105 of the new segment, and the Machine Translation Model ID 1110 that was used (or is to be used) to generate the initial translation. Further, in an embodiment, the Smart Edit Application 130 may determine the size and scope of the new segment, and any other identified linguistic markers. In one embodiment, when processing a new source segment, the Smart Edit Application 130 may utilize the aggregate edit score corresponding to the scope of the new segment.
In one embodiment, the Mapper Component 140 builds a rules-based table for the Pattern Model 180. For example, in such an embodiment, Smart Edit Application 130 may determine the appropriate Pattern Model 180 to use (or the appropriate row(s) in the Pattern Model 180 table) based on the Domain ID 1105 and Machine Translation Model ID 1110 associated with the new segment. Then, based on one or more of the Segment Size 1115, Segment Scope 1120, Other Linguistic Markers 1130, and aggregate scope edit score corresponding to the new segment, the Smart Edit Application 130 can identify the appropriate row in the rules-based table. That is, in such an embodiment, the Smart Edit Application 130 searches for a row in the Pattern Model 180 that corresponds to segments with the identified Domain ID 1105, Machine Translation Model ID 1110, and Segment Scope 1120. In some embodiments, the Pattern Model 180 may further specify the Segment Size and other factors, as discussed above. Once the row is identified, in such an embodiment, the Smart Edit Application 130 determines the s-score associated with the identified row. As discussed above, in one embodiment, the s-score is a binary result indicating whether the segment should be flagged as an “excellent” match or not. In some embodiments, the s-score is a value that is compared to one or more predefined thresholds to determine whether the segment should be marked as “excellent.”
In one embodiment, the Mapper Component 140 builds a predictive Pattern Model 180 by applying analytical modeling techniques based on the map table. In some embodiments, some portion of the map table (i.e., some percentage of the Edit Logs 175) may be set aside as validation data while the remainder is used as training data. In one embodiment, one or more modeling algorithms may be utilized to generate a number of Pattern Models 180. The most accurate of these can then be identified using the validation data. In this way, the identified Pattern Model(s) 180 can be used to process new segments, in order to identify excellent segments that need no further processing.
In some embodiments, the maturity of the system (i.e., of the machine translation model(s)) is determined and tracked over time to ensure that the generated machine translations are high quality. In some embodiments, the maturity of the machine translation model is tracked for each scope. For example, as discussed above, small segments tend to exhibit less linguistic noise than larger segments, and a machine translation model may therefore reach maturity with respect to small segments before it does so with respect to larger segments. In some embodiments, the Checker Component 135 and/or Reviewer Component 145 may only identify excellent segments if the maturity of the corresponding scope exceeds a predefined threshold. In some embodiments, the maturity of the machine translation model with respect to each scope or class is defined based on the aggregate edit score for the scope or class. In some embodiments, the maturity is defined based on the linguistic vector for the corresponding scope or class. For example, in one embodiment, the MaturitySM of a machine translation model for a particular ClassSM is given by formula 8, below:
In some embodiments, the Pattern Models 180 may be periodically refined, or new Pattern Models 180 may be periodically generated. For example, as translations are completed, additional Edit Logs 175 and entries in the Translation Memory 160 may be added. Similarly, the machine translation models may be refined with this additional data. In one embodiment, the linguistic vectors are periodically recalculated for each class or scope, and the edit scores may be recomputed. Similarly, in an embodiment, the maturity of the machine translation models may be recomputed in order to verify that the machine translations are of sufficient quality.
The method 1200 then proceeds to block 1225, where the Smart Edit Application 130 determines whether the generated s-score exceeds a first threshold. In some embodiments, the s-score is a binary value, and this step simply determines what that value is. In other embodiments, the s-score is a value in a range. If the s-score exceeds the first threshold (e.g., it is above the first threshold, or it is a “yes”), the method 1200 proceeds to block 1230, where the Smart Edit Application 130 (e.g., the Checker Component 135) marks the segment as excellent or auto-substitution. As discussed above, in some embodiments, segments marked as “excellent” may be subject to reduced downstream processing. For example, in one embodiment, segments marked as “excellent” may be subject only to proofreading, or may be finalized with no further review or processing required. In such an embodiment, the segment may have a translation generated based on a Dictionary 165, for example. As illustrated, the method then proceeds to block 1255, where it terminates. In some embodiments, however, these segments may be additionally processed by a reduced downstream operations, such as a light post edit process.
If it is determined, at block 1225, that the segment is not “excellent,” the method 1200 proceeds to block 1235, where a machine translation is generated for the segment. As discussed above, in some embodiments, only machine match segments are processed with the Pattern Models 180 to determine whether they can be marked as “excellent.” In some embodiments, however, all segments may be processed via Pattern Models 180. In such an embodiment, there may be no need to generate the machine translation, if a match has already been identified. At block 1240, the segment is transmitted to the Reviewer Component 145. At block 1245, the Reviewer Component 145 again analyzes the segment with a Pattern Model 180 to determine whether the s-score exceeds a second threshold. In some embodiments, the Reviewer Component 145 may utilize a different Pattern Model 180 or different threshold than the Checker Component 135. If this renewed analysis determines that the segment should be marked “excellent,” such that no further processing is required, the method 1200 proceeds to block 1250, where the segment is flagged as “excellent” or “autosub” and the method terminates at block 1255. Otherwise, the method proceeds to block 1255 to terminate, and the segment is sent for downstream processing (i.e., post edit).
The descriptions of the various embodiments of the present disclosure have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.
In the preceding, reference is made to embodiments presented in this disclosure. However, the scope of the present disclosure is not limited to specific described embodiments. Instead, any combination of the preceding features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Furthermore, although embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the preceding aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).
Aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.”
The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
Embodiments of the invention may be provided to end users through a cloud computing infrastructure. Cloud computing generally refers to the provision of scalable computing resources as a service over a network. More formally, cloud computing may be defined as a computing capability that provides an abstraction between the computing resource and its underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. Thus, cloud computing allows a user to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in “the cloud,” without regard for the underlying physical systems (or locations of those systems) used to provide the computing resources.
Typically, cloud computing resources are provided to a user on a pay-per-use basis, where users are charged only for the computing resources actually used (e.g. an amount of storage space consumed by a user or a number of virtualized systems instantiated by the user). A user can access any of the resources that reside in the cloud at any time, and from anywhere across the Internet. In context of the present invention, a user may access applications (e.g., the Smart Edit Application 130) or related data available in the cloud. For example, the Smart Edit Application 130 could execute on a computing system in the cloud and process content to be translated. In such a case, the Smart Edit Application 130 could generate and store Pattern Models 180 at a storage location in the cloud. Doing so allows a user to access this information from any computing system attached to a network connected to the cloud (e.g., the Internet).
While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.
| Number | Name | Date | Kind |
|---|---|---|---|
| 8494835 | Seo et al. | Jul 2013 | B2 |
| 8626486 | Och | Jan 2014 | B2 |
| 9336207 | Martinez Corria et al. | May 2016 | B2 |
| 9535905 | Martinez Corria et al. | Jan 2017 | B2 |
| 9558182 | Chenon et al. | Jan 2017 | B1 |
| 20020111789 | Hull | Aug 2002 | A1 |
| 20090326913 | Simard et al. | Dec 2009 | A1 |
| 20110193797 | Unruh | Aug 2011 | A1 |
| Entry |
|---|
| Trusted Translations, “Post Editing of Machine Translation,” <http://www.trustedtranslations.com/translation-services/post-editing.asp> [Accessed Online May 16, 2018, 2 pages. |
| Moravia, Global Blog, Posted by Lee Densmer, Aug. 19, 2014 “Light and Full MT Post-Editing Explained,” <http://info.moravia.com/blog/bid/353532/Light-and-Full-MT-Post-Editing-Explained> [Accessed Online May 16, 2018]. |
| Number | Date | Country | |
|---|---|---|---|
| 20190354593 A1 | Nov 2019 | US |
