Patent Description:
Service automation systems require a large number of applications compliant with the Application Packaging Standard (APS). The Application Packaging Standard (APS) is a standard that defines a technology for integrating application software with hosting platforms. Integration of an application with such hosting platforms is implemented by creating an APS package for the application, and the application is called an APS application in this case. Development on an APS platform allows for universal use of an application on different hosting platforms. Such applications are also deployed in various regions of the world in native languages and/or dialects. In order for such applications to be used, their Graphical User Interfaces (GUI) are sometimes deployed using the local language. For example, where a GUI might have a text element that is in English when presented to a user in the United States (U. ), the same GUI element may have the same text translated into Russian, when presented to a user in Russia. Using a local language (as opposed to English only) for GUI elements allows for a customized and improved user experience.

Internationalization (i18n) is the process of developing an application such that the strings and other locale-specific bits (such as date or currency formats) can be abstracted out of the application so they can be localized for languages and cultures easily. Localization (l10n), is the process of adapting applications and text to enable their usability in a particular cultural or linguistic market by providing translations and localized formats for the abstracted bits. For example, making a U. application accessible to Australian or British users may require a little more than a few spelling corrections. But to make a U. application usable by Japanese users, or to make a Korean application usable by German users, will require the software to operate not only in different languages, but also to use different input techniques and presentation conventions.

Developing a GUI (and the GUI elements therein) for each language and for each application is not a viable proposition. The time, effort and money required to develop so-called "language native" GUIs can be burdensome when trying to deploy an application in multiple regions of the world.

To reduce the burden, software and development platforms, such as for example, the APS platform, allow for GUI elements to be localized and translated. This allows for a GUI, when rendered, to be in a language that is native to the region (or the user). However, traditional translations and conversions of the GUI interface elements do not present consistently. This can be because the character set that comprises the alphabet of one language is different from another language; the change in spatial characteristics renders the text in the translated language larger (or smaller); or there is meaning "lost in translation.

Furthermore, when a GUI is developed or improved, the amount of data rendered on the screen to the end user may increase, including any text messages that the user sees as part of the GUI. In particular, the number of lines, marks of the interface elements, and screen forms tend to increase. According to the APS standard, all application interface elements have to be localized and internationalized. However, the interface lines and elements are not always properly formatted after they are included into the application code. As a result, the end user can observe glitches caused by a partial localization and translation of messages inside the application.

For example, referring now to <FIG>, there is shown an embodiment of a conventional method for translation of un-localized lines of an APS compatible application, generally at <NUM>. The conventional method includes step <NUM> of collecting the source code; step <NUM> of importing of localization through msgmake posts; step <NUM> of creating portable objects (. po) message files; step <NUM> of transferring the msgmake posts to a technical writer who drafts translations for the un-localized lines; step <NUM> of adding the translation; step <NUM> of building the APS package by exporting the localized message in JavaScript Object Notation (JSON); which results at <NUM> with the APS package with internationalization files.

In the conventional method <NUM>, not all lines can be presented and localized into the interface correctly. The reasons for this can include, but are not limited to, incorrect format of the localities, a processor error, an incorrect key, lack of available translations, or typos or missing files relating to an additional locality, to name a few non-limiting examples. This results in an incomplete implementation of required scenarios and in high costs associated with checks and verifications.

Ideally, the above problems can be prevented in the application development phase. Furthermore, automated and semi-automated checks of correctness of translation of GUI elements are desired. This will help improve the checks and reduce costs associated with manual verification. Lastly, a method for timely detection of localization errors within the application lifecycle management is desired.

The publication "<NPL>) generally describes internationalization and localization. No method for automated internationalization or localization is disclosed. <CIT> relates generally to localization of application content, and more particularly to a method and system for localizing mobile application content to one or more target localities. <CIT> relates to a method and processing unit for providing localized version of a software application having text elements, e.g. for presentation to a user.

There is a need for a method for automated detection, correction, and translation of un-localized lines.

Accordingly, the present disclosure is directed to a method for automated detection, correction and translation of un-localized code lines that substantially obviates one or more of the disadvantages of the prior art (as further discussed below). Specific embodiments are defined in the dependent claims.

In one aspect of the present disclosure, a method for periodic checking of localized lines in the application source code before the assembled application is propagated into message files (*. po) is provided. In another embodiment, an automated translation of lines for all supported application languages is provided. The lines and their translations, which are provided in i18n JSON files, are validated against the message files. According to an exemplary embodiment, the un-localized lines are checked in the source code using a localization marker. According to the APS, a special trap (i.e., a hook) is used for aps msgmake utility in order to derive localization data from a set of aps command line tools for assembling a user interface.

Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings.

In at least one embodiment of the present disclosure, a method for periodic checking of localized lines in the application source code before the assembled application is propagated into message files (*. po) is provided. In another embodiment, an automated internationalization of lines for all supported application languages is provided. The lines and their translations are validated against the message files (*.

According to the exemplary embodiment and with reference to <FIG>, the localized lines are marked in the source code <NUM> using a localization marker. In an embodiment using the APS, a special trap (i.e., a hook) is used for the aps msgmake utility <NUM> in order to derive localization data from a set of aps command line tools for assembling a user interface. The aps msgmake command extracts the translation strings into message files (*. po), one file per language. po message file is a plain-text file, representing a single language that contains all available translation strings and their interpretation (translation) in the given language. This file is a convenient way for translators to provide the interpretation of the translation strings in the target language. po message file is made up of many entries, each entry describes the relation between an original untranslated string and its corresponding translation:
<IMG>.

Using the above example, a translation in Spanish can be expressed as follows:
msgid "Diskspace - Usage Only"
msgstr "Espacio en disco - Solamente Uso".

According to the exemplary embodiment, two exemplary formats of a hook (i.e., a localization marker) are used:.

The pair of underscores for *. java and single underscore for *. js function is a hook that makes a string available for translation. For example, __("string to translate") makes the aps msgmake command create the msgid "string to translate" and msgstr "translated string" pair in. po files <NUM>. In the general case, a string may contain mapped parameters that should not be translated. The mapped parameters must be enclosed between a pair of underscores "__". In the following example, the msgKey string contains parameters, which values must be found in the paramObjects mapping string:
_(msgKey, paramObjects).

It will be further appreciated that the localization marker can be used in a short or full format. For example:
JavaScript (*. js):
Short format: _("User__username__created")
Full format: _("User __username__ created", {"username":"John Smith"})
Java (*. java):
Short format: __("User __username__ created")
Full format: __("User __username__ created", {"username": "John Smith"}).

Accordingly, all of these lines are added into the. po message file, and subsequently into JSON as follows:.

The __() function is used to localize the string @msgKey. For example, @msgKey is actually a string "Found __itemsCount__ item(s). " This string contains the itemsCount parameter, wrapped by a pair of underscores. The parameter is defined by the mapping string {"itemsCount":counter}. So, if aps msgmake meets the following code when parsing a JavaScript code:
<IMG>.

The resulting. po message file <NUM> is considered to be correct and is used as a basis for a dictionary of localization samples (i.e., localization patterns). Since the variability of code is rather high, it is impossible to determine the lines to be localized in the product source code with a high degree of accuracy. According to the exemplary embodiment, the lines of the source code of the keys that have been written into the. po message file of native locality en_US. po are automatically considered and collected as the localization samples.

As shown in <FIG>, a source code analyzer <NUM> may be used to review various sources of code <NUM>. Once a line with a localization marker is found, the source code analyzer <NUM> saves everything preceding the localization marker within the current line into a database (i.e. database <NUM>):.

The above record is called the localization pattern. For example in the following:
var warn =_("Assign the serviceName service to yourself to start using it. ", {serviceName: serviceConstants. SERVICE_NAME}, the localization sample will be "var warn.

According to the exemplary embodiment, the localization samples (patterns) are generated based on a plurality of rules. In at least one embodiment of the present disclosure, If a line in the * java file contains a declaration of the text constant (i.e., a text "static final String" or "final static"), the application considers everything positioned before the string including the actual word "String" to be a localization pattern. Thus, for the string public final static String PASSWORD NOT CHANGED = __("Password Not Changed") the localization pattern is public final static String.

When there is no text in front of the localization marker (e.g., in a multi-line string), the source code analyzer <NUM> takes everything located one line above as a localization pattern. If the above line contains a string with the localization marker, the application moves to the next line above. For example, for a line:
<IMG>
<IMG>
the localization pattern is:
return buildNotification (apsAccountUuid, apsUserUuid, entity, domainName, NotificationMessageStatus. inProgress).

If the multi-line string is encountered during a search based on an already generated localization pattern, the source code analyzer <NUM> reads the string to the semicolon, which is interpreted as a string end. All other borderline cases are resolved during a code review so the mechanism of creation of localization patterns is implemented within the same standard. According to one exemplary embodiment, the localization marker is added automatically, after a list of localization patterns is formed. After a list of localization patterns is formed, the source code analyzer <NUM>, using the saved localization patterns, looks for entries in all files with the particular FileExtention (e.g., JS). For example, if there is a sample label: marker, then find the end of the line where this is a sample string marker (e.g. double quotes), and then extend this string with alocalization marker if it did not exist. For example:
Label: "test string" ---> label:_("test string").

Then, a line propagation process (wherein all code lines with a localization marker are moved to PO files), via the aps msgmake tool is implemented as shown in <FIG>. At step <NUM>, the aps msgmake facilitates placing the content which is placed inside the quotation marks inside the message file (*. po) and this becomes a localization key.

After all of the localization keys are added into the. po message file of the native locality (e.g. "en_US. po"), a locale analysis is started <NUM>. Locale analyzer parse a native language *po message file for all the existing msgID's. After that the tool compares the native and additional languages files and extends the additional languages files with msgID's which are not presented in it. Then the line internationalization process <NUM> is started using any of the available libraries configured for working with gettext files (*. It will be appreciated that gettext files are based on an internationalization and localization (i18n) system commonly used for writing multilingual programs. For example, for the Python programming language, the "Polib" library can be used. Google Translate API can be used for automated translation of lines.

For each msgID (strings in *po files consist of a keys), a translation request is sent to a translation engine, like Google Translate using the Google Translate API in JSON format, to name one non-limiting example.

If the request is executed successfully, the server returns an "OK" response and a translation result in JSON:
<NUM> OK
{
"data": {
"translations": [
{
"translatedText": "Nueva factura emitida" (Spanish)
]
}
}.

According to the exemplary embodiment, the translation is requested for all languages supported by the APS application or only for the languages having the. po message file present in the system. The translation selection is made based on an internationalization script launching mode. The translated lines are also written into the database (i.e. database <NUM>) in the following format:.

According to the exemplary embodiment, the appropriate translated lines are written into appropriate gettext files. Then the translation validation manual process <NUM> is started. Responsible Tech Writer reviews strings that were automatically translated.

At step <NUM>, after the APS application (i.e., APS package <NUM>) is assembled, the content of the message file (*. po) is converted into the localization file *.

According to the exemplary embodiment, the lines are validated between the. po message files and JSON <NUM>. After the package is assembled, the validation script imports all of the localization keys and the corresponding localization values from the. po message files. Then, the script checks for the file with the same name and the file extension *. Subsequently, the script compares the keys and the values loaded into memory against the keys and the values in the JSON file. If the key or the value is not found, an automated error report is created <NUM>, and can be sent to an application developer, to name one non-limiting example.

Referring now to <FIG>, there is shown a flowchart of a method for checking for un-localized lines in a source code populating a database with localization samples, in accordance with one embodiment of the present disclosure. In step <NUM>, the. po message files are generated by an aps msgmake tool as disclosed above. In at least one embodiment of the present disclosure, the aps msgmake command extracts the translation strings into. po message files, one file per language. This file is a convenient way for translators to provide the interpretation of the translation strings in the target language. The aps msgmake utility uses a special trap (i.e., a hook) in order to derive localization data from a set of aps command line tools for assembling a GUI.

In step <NUM> a native locality. po message file is parsed. For example, en _US. po is a locality. po message file for the English language (en) in the United States (US). po message file name is in the form of ll_CC. The two-letter primary code (ll) is defined by the ISO <NUM>-<NUM> language specification. The two-letter subcode (CC) is interpreted according to the ISO <NUM>-<NUM> country specification. The language part is always written in lower case and the country part in upper case. The separator is underscore ("_"). In at least one embodiment of the present disclosure, a. po message file is a plain-text file, representing a single language that contains all available translation strings and their interpretation (translation) in the given language. It will be appreciated that a. po message file may be made up of many entries, each entry describing the relation between an original untranslated string and its corresponding translation:.

In step <NUM>, the process determines whether a string msgid already exists in a database (e.g. database <NUM>). If the msgid exists, the process returns to step <NUM>. Otherwise, the process gathers localization patterns in step <NUM>. Then, the process saves the localization patterns into database <NUM> and sends a report <NUM> to a responsible party, such as, for example, a technical writer in step <NUM>. It will be appreciated that report <NUM> contains newly added localization patterns that can be analyzed by developer or technical writer to exclude it and make an exception to not recognize such string(s) as localization patterns. In step <NUM>, the process determines whether it has reached the end of file (EOF) of the. po message file. If the EOF has been reached, the process ends in step <NUM>. Otherwise, the process returns to step <NUM>.

Referring now to <FIG>, there is shown a flowchart of a method for the automated internationalization of lines in a source code populating a database with localization samples, in accordance with one embodiment of the present disclosure. In step <NUM>,. po message files are generated by an aps msgmake tool as disclosed above. In at least on embodiment, *po files can be retrieved from the previous stage after working of source code analyzer (second iteration of <NUM> step). In at least one embodiment of the present disclosure, the aps msgmake command extracts the translation strings into. po message files, one file per language. This file is a convenient way for translators to provide the interpretation of the translation strings in the target language. The aps msgmake, utility uses a special trap (i.e., a hook) in order to derive localization data from a set of aps command line tools for assembling a GUI.

In at least one embodiment of the present disclosure, the process automatically creates a plurality of. po message files for each locality where a translation is desired. It will be further appreciated that the. po message file for each locality comprises the each msgid that needs to be translated. In step <NUM>, a native locality. po message file is parsed as disclosed in step <NUM>. If, in step <NUM>, the msgid exists in an additional locality, the process sends the msgid via a request to a translation engine, such as, for example, the Google Translate API, via network <NUM> in step <NUM>, and receives a translated string. Otherwise, the process extends the additional locality <NUM> by the msgid (i.e. the process adds the msgid to the additional locality if necessary) and moves to step <NUM>. Then, in step <NUM>, the process saves the translated strings into a message file, the message file being provided for each additional locale and into database (e.g. database <NUM>) and sends a report. In step <NUM>, the process checks if it has reached the end of file (EOF) of the. po message file. If the EOF has been reached, the process ends in step <NUM>. Otherwise, the process returns to step <NUM>.

Referring now to <FIG>, there is shown a flowchart of a method for validation of lines between. po message files and JSON, in accordance with the exemplary embodiment. In step <NUM>, the process acquires a msgid from the. po message file for a native locality. In step <NUM>, the process parses a locality reference file (i.e. JSON i18n files) for all existing localities. In step <NUM>, the process determines whether a key/value in the. po message file is equal to the locality reference file (i.e. the JSON i18n file) except native locale where values are empty by default. So, for the native locale compares only values of keys. If the key/value in the. po message file is equal to the locality reference file, the process determines whether the JSON (locality reference file) file has reached the end of file (EOF) in step <NUM>. If the JSON file has reached the end of file (EOF), the process ends in step <NUM>. Otherwise, the process moves to step <NUM>. If, in step <NUM>, key/value in the. po message file is NOT equal to the locality reference file, the process saves absent strings into a database <NUM> and sends a report to a responsible party (e.g. the responsible technical writer) in step <NUM> and moves to step <NUM>. In step <NUM>, the errors are processed manually.

Referring to <FIG>, there is shown a system and components for automated detection, correction, and translation of un-localized lines, generally at <NUM>. This description is presented in terms of programs, data structures or procedures executed on a computer or network of computers. The software programs implemented by the system may be written in any programming language - interpreted, compiled, or otherwise. These languages may include, but are not limited to, PHP, ASP. net, HTML, HTML5, Ruby, Perl, Java, Python, C++, C#, JavaScript, and/or the Go programming language. It should be appreciated, of course, that one of skill in the art will appreciate that other languages may be used instead, or in combination with the foregoing and that web and/or mobile application frameworks may also be used, such as, for example, Ruby on Rails, Node. js, Zend, Symfony, Revel, Django, Struts, Spring, Play, Jo, Twitter Bootstrap and others. It should further be appreciated that the systems and methods disclosed herein may be embodied in software-as-a-service available over a computer network, such as, for example, the Internet. Further, the present disclosure may enable web services, application programming interfaces and/or service-oriented architectures through one or more application programming interfaces or otherwise.

<FIG> shows a system for automated detection, correction, and translation of un-localized lines. In at least one embodiment of present disclosure, the system comprises a user GUI <NUM>, server <NUM>, database <NUM>, and computer network <NUM>.

The user GUI <NUM> may be configured to transmit information to and generally interact with a web service and/or application programming interface infrastructure housed on server <NUM> over computer network <NUM>. The user GUI <NUM> may include a web browser, mobile application, socket or tunnel, or other network connected software such that communication with the web services infrastructure on server <NUM> is possible over the computer network <NUM>.

The user GUI <NUM> includes one or more computers, smartphones, tablets, wearable technology, computing devices, or systems of a type well known in the art, such as a mainframe computer, workstation, personal computer, laptop computer, hand-held computer, cellular telephone, MP3 player, or personal digital assistant. The user GUI <NUM> comprises such software, hardware, and componentry as would occur to one of skill in the art, such as, for example, one or more microprocessors, memory systems, input/output devices, device controllers, and the like. The user GUI <NUM> also comprises one or more data entry means (not shown in <FIG>) operable by customers of the user GUI <NUM> for data entry, such as, for example, voice or audio control, a pointing device (such as a mouse), keyboard, touchscreen, microphone, voice recognition, and/or other data entry means known in the art. The user GUI <NUM> also comprises a display means which may comprise various types of known displays such as liquid crystal diode displays, light emitting diode display, and the like upon which information may be displayed in a manner perceptible to the customers. It will be appreciated that user GUI <NUM> may further comprise such software, hardware, and componentry as would occur to one of skill in the art, to operably perform the functions allocated to the user GUI <NUM> in accordance with the present disclosure.

The database <NUM> is configured to store information generated by the system and/or retrieved from one or more information sources. In at least one embodiment of the present disclosure, database <NUM> can be "associated with" server <NUM> where database <NUM> resides on server <NUM>. Database <NUM> can also be "associated with" server <NUM> where database <NUM> resides on a server or computing device remote from server <NUM>, provided that the remote server or computing device is capable of bi-directional data transfer with server <NUM>, such as, for example, in Amazon AWS, Rackspace, or other virtual infrastructure, or any business network. In at least one embodiment of the present disclosure, the remote server or computing device upon which database <NUM> resides is electronically connected to server <NUM> such that the remote server or computing device is capable of continuous bi-directional data transfer with server <NUM>.

For purposes of clarity, database <NUM> is shown in <FIG>, and referred to herein as a single database. It will be appreciated by those of ordinary skill in the art that database <NUM> may comprise a plurality of databases connected by software systems of a type well known in the art, which collectively are operable to perform the functions delegated to database <NUM> according to the present disclosure. Database <NUM> may also be part of distributed data architecture, such as, for example, a Hadoop architecture, for big data services. Database <NUM> may comprise relational database architecture, noSQL, OLAP, or other database architecture of a type known in the database art. Database <NUM> may comprise one of many well-known database management systems, such as, for example, MICROSOFT's SQL Server, MICROSOFT's ACCESS, MongoDB, Redis. Hadoop, or IBM's DB2 database management systems, or the database management systems available from ORACLE or SYBASE. Database <NUM> retrievably stores information that is communicated to database <NUM> from user GUI <NUM> or server <NUM>.

Claim 1:
A method for automated detection, correction, and translation of un-localized lines of source code (<NUM>) in Application Packaging Standard-compliant application interfaces, the method comprising the steps of:
a. receiving at least one source code file;
b. generating at least one message file (<NUM>) from the at least one source code file for at least one first locale, the at least one message file (<NUM>) comprising at least one message id, and at least one first locale of the message id in the at least one source code file;
c. parsing each of the at least one message files (<NUM>) and retrieving the at least one message id, checking the at least one message id to see if it already exists in a message id database;
d. generating and saving into the message id database, a plurality of localization samples using at least the context of the at least one message id in the at least one source code file;
e. checking one of the at least one message id to see if it exists in at least one further locale (<NUM>) which is different from the first locale, and if it does, proceeding to step (g), if it does not, proceeding to step (f);
f. extending the at least one further locale by the one of the at least one message id, and returning to step (e) to check a next of the at least one message id until all message ids of the at least one message id have been checked;
g. requesting a translation to a translation engine and receiving a translated code string from the translation engine, recording the translated code string in the message id database;
h. generating a report to a reviewing party;
i. generating a plurality of presentation files for presentation via a GUI;
j. parsing the plurality of presentation files to verify if the plurality of presentation files has the same message id and translated code string as the at least one further locale;
k. updating the plurality of presentation files by the message id and translated code string if the message id and translated code string are not in the plurality of presentation files;
l. correcting translation mistakes of the plurality of presentation files and reporting about changes to the reviewing party.