Patent Application
20190171719
Illustrated embodiments generally relate to advanced technical translation, and more particularly terminology proposal engine for target language equivalents.
Enterprise products having a global market are designed and developed to be multi-lingual to support customers across the globe. Some languages are widely spoken and technical terminologies are readily available in those languages, while some languages are evolving with time and technical terminologies are not readily available. Typically, enterprises hire native speakers to manually translate a source technical term to a target technical term. In some cases, existing language translators are used to translate to a desired target language. Most of the existing language translators use English language as an intermediate language to translate from a source language to destination language, and this technique has limitations in terms of accuracy of translation. Manual translation depends on the skill of translator and is time consuming, whereas, the existing language translators are limited in capability. Translating technical content with accuracy and efficiency is challenging.
The claims set forth the embodiments with particularity. The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. Various embodiments, together with their advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
FIG. SA is a flow diagram illustrating an exemplary use case of terminology proposal engine for determining target language equivalents, according to one embodiment.
FIG. SB shows tables with computed target language equivalents, according to one embodiment.
Embodiments of techniques of terminology proposal engine for determining target language equivalents are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. A person of ordinary skill in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In some instances, well-known structures, materials, or operations are not shown or described in detail.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one or more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Customer defined metadata may include other parameters to be included or excluded for the term proposal process. Some of the parameters are domain that indicates the subject area such as medical, financials, manufacturing, supply chain, sports, political, construction, urban, reference treatise, etc. Values configured for the domain indicates that a selected subject area is preferred while determining target language equivalents. For example, as shown in 225, customer defined metadata such as domain with custom options, such as ‘financials’, user with options such as ‘user ID’, and timeframe within which target language equivalents are to be considered, for example, time frame range ‘01.01.2011‘ to’01.01.2012’, is configured to determine target language equivalent within this time frame and not from historic data. The configuration profile is saved in a configuration and statistical database with the received configuration parameters. The configuration profiles are configured as shown above, and the configuration profiles are provided as input to the proposal engine to determine the target language equivalent.
When the input terminology is provided in the source language, through the create terminology UI 335, the proposal engine 315 determines a set of target language equivalents based on a set of approaches. The set of approaches may be pre-defined when the configuration profile is not defined, and the set of approaches may be user-defined when the configuration profile is defined. Based on the configuration profile selected, statistics are computed for the individual target language equivalents, and a target language proposal is determined from the set of target language equivalents. The example below illustrates the user-defined set of approaches based on the selected configuration profile. For the input terminology provided in the source language, the first approach is to ‘use English source term as is’. For example, an input terminology is provided in source language English, and using the first proposal a target language equivalent in ‘Spanish for Columbia’ is identified. The input terminology ‘simultaneous engineering’ and ‘concurrent engineering’ are provided as input. In the first approach, English source term is used as is, and accordingly ‘simultaneous engineering’ and ‘concurrent engineering’ are proposed as equivalent choice in target language. For the input terminology provided in the source language, the second approach is to ‘use calque’, e.g., a literal word-for-word or root-to-root translation of a word or phrase from another language. For example, the input terminology ‘simultaneous engineering’ and ‘concurrent engineering’ are provided in English, and using the second proposal a target language equivalent in ‘Spanish for Columbia’ is identified. In the second approach, ‘use calque’ is applied on the English term ‘simultaneous engineering’ and the translation ‘ingeniería simultánea’ is identified as equivalent choice in the target language.
When the input terminology is provided in the source language, the third approach is to ‘use English language or any reference language’ as intermediate reference language before translating to a target language. For example, the input terminology i.e., ‘simultaneous engineering’ and ‘concurrent engineering’ in English language is translated to an intermediate language ‘ingeniería simultánea’ in Spanish, and the intermediate Spanish translation is subsequently translated to the target language ‘ingeniería simultánea’ in ‘Spanish for Columbia’. When the input terminology is provided in a source language, a fourth approach is to ‘use multi-lingual term data to verify the translation in a multichannel approach’. For example, an input terminology is provided in English and the using the fourth proposal a target language term in ‘Spanish for Columbia’ identified. For the input terminology i.e., ‘simultaneous engineering’ and ‘concurrent engineering’ in English language, over 90% of the target language terms such as Italian, French. Romanian, etc., are translated to ‘ingenierí’ and ‘simultánea’, and therefore the target language proposal ‘ingeniería simultáneai’ is provided as proposal.
When the input terminology is provided in the source language, through the create terminology UI 335, the proposal engine 315 determines the target language equivalent based on the set of approaches explained above. In one embodiment, the set of approaches can vary based on the configuration profile selected by administrator. Based on the configuration profile chosen, corresponding set of approaches are used to determine the target language equivalent for the given input terminology in the source language. In one embodiment, the create terminology UI 335 may be used to create a terminology along with a definition in a specific language. The created terminology UI 335 may be used to determine the target language equivalent. The terminology can also be created by automatically uploading the terminology via Term Base eXchange (TBX). TBX is an international standard for the representation of structured concept-oriented terminological data. TBX defines an XML format for the exchange of terminologies between various tools/applications. Using the TBX standard, the terminologies can be automatically uploaded from various applications to the terminology database 325.
’ in ‘Russian’. The translation ‘
’ is provided as target language proposal to the customer. If the customer accepts the proposal, ‘
’ is stored in the terminology database along with metadata 430 indicating the ‘German’ input terminology corresponding to this translation. Terminology maintenance tool 435 may be used to store the translation in the terminology database. If the customer rejects the target language proposal, the user action of rejection is saved/recorded in a configuration and statistical database 440. For example, an input terminology is provided in ‘English’ and a target language term in ‘French’ is determined. The source language i.e., ‘cloud computing’ in ‘English’ language is translated to the target language equivalent ‘informatique’ in ‘French’. The translation ‘Informatique’ is provided as target language proposal to the customer. If the customer rejects the proposal, the rejection action performed for the input terminology is stored in the configuration and statistical database along with metadata indicating the ‘English’ input terminology corresponding to this translation. When a subsequent request comes from a different customer for the input terminology ‘cloud computing’ in ‘English’ language to be translated to the target language equivalent in ‘French’, the proposal ‘Informatique’ is never provided to the customer because it was the rejected proposal. For the specific customer or user, action corresponding to the displayed target language proposal is used to recognize a pattern, and based on the recognized pattern, the configuration profile is implicitly modified. For example, if the user rejects the target language proposal provided from using calque, this pattern may be used to implicitly modify the weight associated with calque approach, so that calque approach is not giving higher weight or priority.
The individual approaches in the pre-defined set of approaches have a corresponding weight associated with them. Based on the weight, statistics are computed for the individual approaches. For example, ‘use English language or any reference language’ 510 may have a weight of 70%, ‘use calque’ 512 may have a weight of 20%, and ‘use English source term as is’ 514 may have a weight of 10%. The proposal engine learns user behavior and implicitly modifies the weights associated with the individual approaches. Based on the user behavior and preference of acceptance/rejection of target language proposals, weights of certain approaches are increased over the others. For the input terminology ‘company code’ in the source language ‘English’, the pre-defined set of approaches, ‘use English language or any reference language’ 510, ‘use calque’ 512, and ‘use English source term as is’ 514, are used to determine the target language equivalents in ‘Italian for Switzerland’. For the input terminology ‘company code’, when the approach ‘use English language or any reference language’ 510 is applied, the proposal engine assumes ‘French’ as related language and provides ‘societa’ as result as shown in 516 in
Upon determining that the configuration profile is available, at 522, a term data is determined based on the configuration profile. The configuration profile includes a user-defined set of approaches 524 such as ‘configuration A’ 526 and ‘configuration B’ 528. The ‘configuration A’ 526 and ‘configuration B’ 528 may define various parameters associated with the configuration profile, and various user-defined approaches. The user-defined approach ‘use French for Switzerland’ as reference language has a configured weight of 300. For example, for the input terminology ‘company code’ in the source language ‘English’, the approach ‘use French for Switzerland’ as reference language, results in a target language equivalent ‘codice aziend’. The target language equivalent ‘codice aziend’ is associated with a weight of 300 as shown in 530 in
Based on the configuration profile, weights of the individual approaches are calculated as explained above. Let the sum of all the approaches, or the maximum score be 1000. The user-defined approach ‘use French for Switzerland’ as reference language, results in ‘codice aziend’ with an associated weight of 300, and this results in a percentage of 300/1000*100=30%. The user-defined proposal ‘use calque’, results in ‘compagnia codice’ with an associated weight of 270, and this results in a percentage of 270/1000*100=27%. The user-defined proposal ‘use English term as is’, results in proposal ‘company code’ with an associated weight of 100, and this results in a percentage of 100/1000*100=10%. The proposal ‘multi-lingual term data is used to verify on a multi-channel approach’, results in ‘società’ with an associated weight is 300*0.8=240, and this results in 240s1000*100=24%. Based on the statistics computed above, the target language equivalent ‘codice aziend’ is determined as a proposed target language equivalent since it has the highest weight/percentage 30%. The target language proposal ‘codice aziend’ is provided to the user, and the user may choose to accept or reject the proposal. There is 100%−30%−24%−27%−100%=19% chance for the user to change the proposal. At 542, the target language proposal ‘codice aziend’ along with the computed statistics i.e., weight 30% is displayed in a graphical user interface associated with a create terminology user interface.
Upon determining that the term data is not available, at 544, based on linguistic feature, a target language proposal is determined. Linguistic features include various types of parameters associated with various aspects. For example, term variant type such as preferred term, forbidden term, abbreviation, synonyms, etc., grammatical aspects such as noun, verb, etc., term length, number of words, etc. The individual linguistic feature may be associated with a weight, and the target language proposal is calculated based on the weight associated with the individual linguistic feature. At 542, the target language proposals along with the percentage of individual proposal is displayed in the graphical user interface to the user, and the user may choose to accept or reject the proposal. A single target language proposal, or multiple language proposal or no language proposal may be displayed depending on the computation performed in the proposal engine. For example, if the target language proposals display three proposals such as proposal A with weight 60%, proposal B with weight 30% and proposal C with weight 10%, and the terminologist accepts the proposal B with weight 30%, then the weight of all the proposals is recalculated since the selected proposal B is not the proposal with maximum weight. The proposal A with weight 60% is recalculated based on the difference as 60%−30% (proposal selected by terminologist)/10% (weight of proposal C)=3%. This results in recalculated weight of proposal A with weight 57% (60%−3%), proposal B with weight 33% (30%+3%) and proposal C (10%−3%) with weight 7%. The recalculated weight is persisted along with the selected terminology in a term database for future reference. Subsequently, when a new target language proposal is performed by a different user, and if that user chooses the proposal B over proposal A, the weight of proposal B will be recalculated and increased. Therefore, in individual target language proposal computations, the weight of target language proposals is recalculated iteratively. In case the terminologist rejects all the target language proposals, the terminologist may provide a loan word as input corresponding to the input terminology. The loan word may be a word or term borrowed from a different language. In one embodiment, the target language proposals may be ranked and the target language proposals above a certain pre-defined threshold of rank may be displayed. The threshold may be provided by the user or terminologist.
Proposal engine has many advantages, and can be used in a wide variety of scenarios such as finding terminology equivalents for a new language where no terminology exists, enhance a language for a new topic area where no reference data exists, etc. The primary advantage is the integration of terminology extraction and analysis combined with the terminology proposal engine in a seamless procedure, as opposed to using separate, non-integrated programs and modules on different platforms, often with wildly-varying interfaces or even different terminology repositories. The ease-of-use of the combined embodiments result in significant savings and increased qualitative and quantitative outputs by designing and providing a single cloud-based platform utilizing a single proposal engine.
In an exemplary scenario, if a terminologist spends X minutes to conduct research on online resources, authoritative resources, etc., and perform translation for a terminology. Using the proposal engine, a target language proposal for the terminology is provided in X/3 or X/4 minutes. This results in significant reduction of research time using the proposal engine. Further, the target language proposals provided by the proposal engine simplifies the research steps that would otherwise require the user to switch between multiple programs and interfaces. When the terminologist approves a translation for a terminology, that approved terminology is stored in the term repository, and is provided in subsequent translation to other terminologists/translators/content creators, thereby saving their time. Terminology research can be a time-consuming process in both translation and authoring. With the increasing speed to market, the rising volume of material, and the growing complexity of processes, having terminology available saves time at every stage of the product cycle. Create terminology UI has the capability of accepting a scanned document, and retrieving an input terminology from the scanned document as input. The proposal engine determines the target language proposal corresponding to the scanned input terminology.
Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated to them, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as Open Data Base Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however that the embodiments can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in detail.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the one or more embodiments are described herein for illustrative purposes, various equivalent modifications are possible within the scope, as those skilled in the relevant art will recognize. These modifications can be made in light of the above detailed description. Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
