Abstract:
Embodiments relate to automatically providing textual context for source strings in a source language that are to be translated by a human translator to target strings in a target language. The source strings are compared against a dictionary of reference strings in the source language. For each source string, one or more of the reference strings that are most relevant, similar, etc., are selected. When a human translator is to translate the source strings, the selected reference strings are presented; each source string has one or more similar/related strings displayable in association therewith. For a given source string, the human translator can use the associated reference strings as a form of context to help estimate the intended meaning of the given source string when translating the given source string to a target string in the target language.

Description:
BACKGROUND 
     Most software programs have text strings that are displayed to provide information to users. However, many software programs are intended to be used by people who speak different languages. Therefore, it is desirable to provide language-specific versions of software programs. To facilitate versions in different languages, many programming languages and software development environments provide tools to allow the displayable text strings of a program to be isolated and conveniently replaced or swapped. Typically, a software developer writes program source code and uses resource references in the source code where text strings (resource strings) are to be incorporated at compile time. The identifiers and the respective resource strings, in English, for example, are stored in a resource file. At compile time, each reference/ID in the source code is replaced with its corresponding resource string in the resource file and is embedded in the compiled program. Another more common approach, discussed below, is to reference a resource file that is loaded or accessed at run time according to a reference thereto. 
     If the program is to be made available for another human language—Spanish, for instance—then a Spanish-specific resource file is built. The same resource string identifiers are used for the strings in the Spanish resource file, which are translated equivalents of the English resource strings. A program project might require many such language-specific resource files, each containing semantically equivalent text strings in respective human languages for which versions of the program are desired. Any of the resource files may be used to create a corresponding language-specific program or distribution thereof. 
     Because software developers are usually only versant in one or a few languages, human translators are employed to translate the source resource strings (authored by the developer) to a target language. Different translators might be employed for each different language for which a resource file is needed. This arrangement may have several problems. Because a language-specific version of a program will require the services of a human translator, the process of building the language-specific version of the program can be significantly delayed while awaiting a corresponding translation. Moreover, because many resource strings are short, translation can be difficult. Lack of information about the context of a resource string (circumstances under which a user will encounter the resource string) can lead to inaccurate translations. While programmer comments can help, such comments take time to write, and for that reason they are often omitted. Screen shots of a program displaying the strings in the source language can be provided to a translator, but this also can be costly and time-consuming. 
     Techniques related to automated context provisioning are discussed below. 
     SUMMARY 
     The following summary is included only to introduce some concepts discussed in the Detailed Description below. This summary is not comprehensive and is not intended to delineate the scope of the claimed subject matter, which is set forth by the claims presented at the end. 
     Embodiments described herein relate to automatically and efficiently providing textual context for source strings in a source language that are to be translated by a human translator to target strings in a target language. The source strings are compared against a dictionary of reference strings in the source language. For each source string, one or more of the reference strings that are most contextually relevant, similar, etc., are selected. When a human translator is to translate the source strings, the selected reference strings are presented; each source string has one or more similar/related strings displayable in association therewith. For a given source string, the human translator can use the associated reference strings as a form of context to help estimate the intended meaning of the given source string when translating the given source string to a target string in the target language. 
     Many of the attendant features will be explained below with reference to the following detailed description considered in connection with the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein like reference numerals are used to designate like parts in the accompanying description. 
         FIG. 1  shows an example of multi-language program project. 
         FIG. 2  shows a translation and build workflow that includes a context identification module to automatically generate, from a context dictionary, context information for a target translation file. 
         FIG. 3  shows an example of the context dictionary. 
         FIG. 4  shows a process performed by one embodiment of the context identification module. 
         FIG. 5  shows an example of a target translation file with textual context information. 
         FIG. 6  shows an example of the resource editor. 
         FIG. 7  shows an example of a computing device. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  shows an example of multi-language program project  100 . Among other objects, the program project  100  has one or more source code files  102 , for example files containing Java or C# source code. The source code file  102  is written to include references  104  to resource text strings  108 . The references  104  can be in any form, for example alphanumeric identifiers  107  that are generally unique to the project  100  or source code file  102 . A resource file  110  contains the identifiers  106  in association with their respective resource text strings  108 . The resource file  110  can contain other types of resources and might also contain a flag or tag indicating a language or culture of the file (e.g., “Spanish”). In effect, the resource file  110  is a dictionary of the strings used in one or more of the source code files  102  in the program project  100 . In one embodiment, a different resource file  110  can be provided for each human language for which the program project is to be made available. In another embodiment, a monolithic resource file can contain all of the translations of the resource text strings  106  which are labeled to identify their language. A resource file can have a variety of known forms, such as Extensible Markup Language (XML, e.g., “resx” files), hypertext markup language, flat files, etc. 
     A development environment and/or a compiler  112  thereof is used to build an executable program  114  which might be one or more files containing processor instructions, bytecode, virtual machine instructions, intermediate language code, etc. In one embodiment, at build time, the compiler  112  (or perhaps a pre-compiler) includes a reference  113  to a resource file  110 . At runtime, the executable program  114  receives a flag or the like that indicates which language or culture (e.g., “English”) is being targeted (possibly provided by the operating system or a user setting). The corresponding resource file  110  (English) is selected, the references  104  in the source code file  102  are used to load the respective resource text strings  108 . In one embodiment, the executable program  114  does not actively select a resource file, but instead uses whichever version of the resource file happens to be in place. Other methods for compiling or configuring culture-specific or language-specific programs are known and may be used instead. 
       FIG. 2  shows a translation and build workflow that includes a context identification module  130  to automatically generate, from a context (or reference) dictionary  131 , context information for a target translation file  132 . The resource file  110  contains the resource text strings  108  in a source human language, for example English. Before the program project  100  is ready for referencing a target human language (e.g., Spanish), a target resource file  110 A in the target language is needed. To that end, a human translator  134  uses a resource editor  136  to produce and edit the target resource file  110 A. The target translation file  132  is used by the resource editor  136  to provide context to the human translator  134 . If the program project  100  is to be used for yet a third human language, a corresponding target translation file  132 A is produced in the same manner by the context identification module  130 . The target translation file  132 A in the third language is then used to provide context for a corresponding human translator  134 A to produce a corresponding resource file  110 B with resource strings in the third language. The resource file  110 B is then provided with the executable program  114  or its contents are incorporated at compile time, according to the particular implementation. 
     Whichever the target language, the target translation file  132  is automatically provisioned, by the context identification module  130 , with context information to help a human translator  134  decide which translations to provide to the target resource file  110 A using a resource editor  136 . The context identification module  130  can be a stand-alone application, part of a web-based application that manages translation workflow, a tool in the development environment, a web service, etc. 
       FIG. 3  shows an example of the context dictionary  131 . In one embodiment, the context dictionary  131  maps text strings in the source language to equivalent strings/phrases in the target language. In another embodiment, the context dictionary  131  is only a set of strings in the source language. In yet another embodiment, the context dictionary  131  is a table with columns for various respective languages; each row containing the same string in different languages. In any case, the dictionary strings can come from any corpus of text strings in at least the same human language as the resource text strings in the source resource file  110 . In one embodiment, the corpus is a historical database or repository of resource strings from resource files and/or source code files, possibly including translations in one or more languages, collected from perhaps many other program projects. In other words, the context dictionary  131  may be a set of strings previously used in other programs (perhaps selected for some relation to the instant program), and possibly with accompanying previously translated equivalents. Content of the context dictionary  131  may first be cleaned, de-duplicated, etc., when being imported from a repository of prior translations or other context-providing source of text. 
       FIG. 4  shows a process performed by one embodiment of the context identification module  130 . At step  150  the context identification module  130  receives the source resource file  110  containing resource strings in the source language. The source resource text strings are extracted. At step  152 , iterating over the source resource text string, for a source resource string currently being processed, one or more of the strings in the context dictionary  131  identified by the context identification module  130  as being most related in some way (e.g., semantic, textual, or topical similarity) to the current source resource string. At step  154 , the target translation file  132  is built storing each of the source resource text strings in association with related strings (in the same language) selected from the context dictionary  131 . In other words, context strings are provided for each of the strings for which translation is expected, thus providing textual context for each of the source resource strings. At step  156  the target translation file  132  is provided to the translation or resource editor  136 . When translating a given source resource string, the human translator can view the context strings associated with the given source resource string to help inform the translator&#39;s decision about what is the best translation to use for the target-language version of the source resource string. 
       FIG. 5  shows an example of a target translation file  132  with textual context information  170 . As noted above, the context identification module  130  receives the resource file  110  in the source language and also accesses the context dictionary  131 . For each of the source resource strings in the resource file  110 , related or relevant strings are identified in the context dictionary  131 . For example, the source resource string “greeting” is found to have five relevant context strings in the context dictionary  131 : “hello world”, “hello”, “hello world Seattle”, “world Seattle”, and “Seattle”, all in the same human language as the source resource strings. Optionally, each of the context strings may also be accompanied by a prior translation thereof (e.g., “halo welt”, “halo”, etc.), that, as discussed below, can serve as additional context for the human translator, or that can also be selected by the human translator to become the target language translation of the corresponding source resource string. The translation file  132  generated or augmented by the context identification module  130  is then provided to the resource editor  136  to be used by the human translator  134 . 
       FIG. 6  shows an example of the resource editor  136 . The resource editor  136  can have any type of user interface through which source resource strings  108  can be viewed, and through which the human translator can input or select target resource text strings  172  (translation strings) to be associated with the source resource strings  108 . The resource editor  136  can be implemented as a web application, a stand-alone executable application (perhaps packaged with the translation file  132 , an ordinary word processor, etc. The user interface of the resource editor  136  also includes some mechanism for displaying context strings in association with their respective source resource strings. In one embodiment, areas where respective source resource strings are displayed can be activated by the user (e.g., by a click, touch, or hover) to display resource-specific context information  170 A. In the example shown in  FIG. 6 , a user has activated the “Greeting” source resource string, causing display of the resource-specific context information  170 A for that resource to be displayed. Alternatively, the context information for each respective source resource string can be displayed in a column of the resource editor  136  (like the “context” column shown in  FIG. 5 ). Note that the manner of delivering contextually similar strings to the translator can depend on the editor implementation. Contextually similar strings can be packaged in a handoff file together, as discussed above. Or, contextually similar strings can be served online on-demand, which can be helpful in an online editor scenario where a handoff file might not be needed. 
     As noted, in one embodiment, the resource-specific context information  170 A consists of only strings in the source language. In another embodiment, as shown in  FIG. 6 , the resource-specific context information  170 A also includes prior target-language translations  174  of the respective context strings, which optionally can be selected for designation as the corresponding target resource string. In  FIG. 6 , although “welt willkommen” is shown as the target resource string (inputted by the human translator  134 ), “halo welt” could have been selected by a user interaction with the resource-specific context information  170 A. In yet another embodiment, the resource editor  136  includes one or more user interface elements to enable the human translator to view context information in any available language. 
     Resource editor  136  features discussed above need not be implemented by the editor per se. The resource editor  136  can be any known general purpose editor or word processor, and the various ways of enabling display and/or selection of context information can be implemented in the translation file  132  that is provided to the resource editor  136 . That is to say, any user interface elements used to display and/or select context information or associated target-language strings can be specified in the translation file  132 . 
     It should be noted that the form and even use of files to exchange information with the human translator  134  is not required. Many techniques can be used to provide the human translator  134  with source resource strings, respective groups of related strings, and means to associate translation strings with the correct resource identifiers. A compiler-consumable target resource file  110 A might not be generated until build time. In another embodiment, the resource editor  136  itself implements the context identification module  130  or communicates with an external context identification module  130 , obtains context-providing strings, and presents in association with the source resource strings. 
     Algorithms usable for context identification module  130  will be described next. In one embodiment, a string similarity measuring algorithm can be used. Any of a variety of edit distance measures can be used to measure similarities between source resource strings and strings in the context dictionary  131 . A combination of minimum similarity measure and maximum matches can be used to select the strings. For example, for a given source resource string, strings in the context dictionary  131  with a similarity score of 0.9 or higher, and at most five thereof, are selected as context-providing strings. 
     In another embodiment, a bag-of-words model can be used to rate and select context-providing strings. With this algorithm, iterating over the source resource strings in the relevant resource file  110 , the given source resource string is broken into constituent words to form a vector, and then distances of the vector to vectorizations of the strings in the context dictionary  131  are used to select the strings therein that are most statistically significant (closest) to the given source resource string. 
     A clustering algorithm can be used to find strings in the context dictionary  131  that are correlated with the source resource strings. With this approach, the context dictionary  131  is passed to a clustering algorithm, which forms clusters of the strings using any known clustering algorithm (e.g., K-Means). A source resource string is then passed through the algorithm which, according to the cluster data of the context dictionary  131 , places the source resource string in one or several of the clusters. Context-providing strings can then be selected based on proximity to the source resource string in the cluster space. Clusters can be omitted if the source resource string is not sufficiently close to the respective cluster centers. For those clusters in which the source resource string is sufficiently close to the center (i.e., strong cluster membership), dictionary strings in the cluster can be selected as context strings based on how close they are to the source resource string. 
     In one embodiment, topic modelling is used to select strings. A topic model assumes that any given string can belong to multiple unspecified abstract topics. Topics can be calculated automatically/statistically over the entire context dictionary  131 , in a form of unsupervised learning. Given this topic model, each source resource string is vectorized, applied to the model, and given scores for various of the abstract topics. The Latent Dirichlet Allocation algorithm is a known implementation of a topic model that is suitable for use. Details are available in “Latent Dirichlet Allocation” (Journal of Machine Learning Research 3 (4-5), pp. 993-1022; by Blei, Ng, and Jordan). 
     Consider a hypothetical example (values not actually computed). Using a topic model, if an input string has the words “hello”, “world”, and “Seattle”, then the strings represented by a topic vector might be, for example:
     String A=[Topic1 (30%), Topic2 (60%), Topic3(5%), Topic4(5%)], and   String B=[Topic1 (40%), Topic2 (60%), 0, 0], and
 
where
   Topic1=[“Hello” (30%), “World” (40%), Seattle (30%)],   Topic2=[“Hello” (20%), “World” (50%), Seattle (30%)],   Topic3=[“Hello” (40%), “World” (40%), Seattle (20%)], and   Topic4=[“Hello” (30%), “World” (50%), Seattle (20%)].
 
To calculate the distance between pairwise topic vectors, any type of distance measure may be used, including, for example: Euclidean distance, Cosine similarity, Hellinger distance, or Kullback-Leibler divergence. For each input source resource string, the top-N closest strings can be selected.
   

       FIG. 7  shows an example of a computing device  300 . One or more such computing devices are configurable to implement embodiments described above. The computing device  300  comprises storage hardware  302 , processing hardware  304 , networking hardware  306  (e.g. network interfaces, cellular networking hardware, etc.). The processing hardware  304  can be a general purpose processor, a graphics processor, and/or other types of processors. The storage hardware can be one or more of a variety of forms, such as optical storage (e.g., compact-disk read-only memory (CD-ROM)), magnetic media, flash read-only memory (ROM), volatile memory, non-volatile memory, or other hardware that stores digital information in a way that is readily consumable by the processing hardware  304 . The computing device  300  may also have a display  308 , and one or more input devices (not shown) for users to interact with the computing device  300 . 
     The embodiments described above can be implemented by information in the storage hardware  302 , the information in the form of machine executable instructions (e.g., compiled executable binary code), source code, bytecode, or any other information that can be used to enable or configure the processing hardware to perform the various embodiments described above. The details provided above will suffice to enable practitioners of the invention to write source code corresponding to the embodiments, which can be compiled/translated and executed.