I did some research and found that Amazon provides a service that does exactly what the client was asking for. The service, called Amazon Translate, is available as one of many services that are available through Amazon Web Services.

In this post, I’ll walk you through the process of getting signed up for Amazon Translate, and then share some code that you can use to add language translation to your own Xojo projects. We’ll use the MBS Xojo CURL Plugin, which makes calling the Amazon Translate API easy. But first, let’s learn a little about Amazon Translate.

Amazon Translate

Amazon Translate is an API that can be used to translate text on demand. You send it text in a “source language,” tell the API what that source language is, as well as the “target language” that you want the text translated to. The API responds with the translated text.

Amazon Translate uses machine learning and neural networks that have been designed specifically for language translation. When performing a translation, the service reads the text one sentence at a time, and reads each word individually, to determine the meaning of a sentence. In other words, the service doesn’t just translate words. Instead, it’s acting as an interpreter. This results in translations that are extremely accurate.

In order to use Amazon Translate, you’ll need an AWS account. If you already have an AWS account, log into the account.

Next, you’ll need to create an “Identity and Access Management” (IAM) user. To do so, under Services, select “IAM” (which can be found in the “Security, Identity, & Compliance” category). This will present you with the IAM Dashboard.

Under Groups, create a new group and give it a recognizable name. For example, you might call the group “translate.” As you are creating the group, give it the “TranslateFullAccess” permission.

Next, create an IAM user. Under Users, click the “Add user” button. Give the user a name such as “XojoTranslater.” For the “AWS access type” be sure to select “Programmatic access.” Add the user to the “translate” group that you created above. There’s no need to assign any tags to the user, so you can skip that step.

And finally, create an Access key for the user. Be sure to make note of both the “Access key ID” and “Secret access key” values that are automatically assigned. You’ll need these in order to make API calls.

The MBS Xojo CURL Plugin

If you don’t already have the MBS Xojo CURL Plugin, download it and install it. To install the plugin, simply drag it into the Xojo “Plugins” folder.

The project will work with an unlicensed version of the MBS Xojo CURL Plugin. In this case, you’ll occasionally see a popup message reminding you to purchase a license. However, I highly encourage you to purchase a license. You can license the plugin individually, or as part of the MBS Complete plugin bundle.

The Xojo Example Project

To demonstrate the Amazon Translate service, I’ve put together an example Xojo desktop project (project file). Before running the application, be sure to set the three App-level properties: AWSAccessKeyId, AWSSecretAccessKey, and the AWSRegion. For the AWSAccessKeyId and AWSSecretAccessKey properties, use the values that you set when you created the Access key for the user. For the AWSRegion, refer to this and use the value that makes the most sense for you.

Once you’ve configured the app, run it, and it will look something like this.

The Xojo Code

Let’s take a look at some of the code.

The AWSTranslator class is a subclass of the CURLSMBS class. The class does two important things: It provides access to a list of the languages that are supported, and provides a method for calling the Amazon Translate API.

The “Languages” property is a dictionary that you can use to get the names of the languages that Amazon Translate supports and the corresponding language codes. The example app uses this dictionary to populate the “Translate From” (SourcePopupMenu) and “Translate To” (TargetPopupMenu) popup menus.

The Translate method creates the payload that gets sent to the Amazon Translate API, and sets special HTTP headers that are needed in order to call the API. But most importantly, it uses the CURLSMBS class’s “SetupAWS” method to configure the CURL instance so that all of the steps that are required to “sign” the API request are done automatically. This is an amazingly convenient function of the MBS Xojo CURL Plugin. You can get a sense of what’s involved in signing the request here.

To translate text using the AWSTranslator class, you create an instance, configure it with your IAM credentials and AWS region, pass it the source language text, the source language code, and the target language code. In the example app, this all handled in the Window1.Translate method. The values are pulled from the App-level properties, as well as the various window controls. Finally, you call the AWSTranslator instance’s Translate method. If the translation is successful, the translated text will be available via the TranslatedText property. If any errors occur, the ErrorType and ErrorMessage properties will be set.

The “Estimated Translation Cost” is calculated whenever the Source Text changes. The value is calculated by taking the length (number of characters) of the Source Text and multiplying it by 0.000015 (the average cost for translating a single character).

Wrapping Up

I’ve been amazed at the speed and accuracy of the Amazon Translate service. And after developing the AWSTranslator class, I was able to quickly and easily add language translation to my client’s middleware app.

I hope you’re equally impressed by the Amazon Translate service, and that you find the AWSTranslator class to be helpful in your own Xojo projects.

Tim Dietrich is a custom software developer based in Richmond, Virginia. To learn more, visit: https://timdietrich.me

A quick Google search turned up an API by FunTranslations: https://funtranslations.com/api/klingon

It has simple usage where you send along the text in English and you get back a JSON result containing the text translated to Klingon. Here’s the result of my 15 minutes of effort to use this in a Xojo desktop app:

This is a pretty simple project with less than 20 lines of code.

You can recreate the layout using a couple TextFields and a Button. I used URLConnection to connect to the web service. You can also add that to the layout by dragging an Object from the Library and changing its Super property to “URLConnection”. I named this object “KlingonAPI”.

In the Button’s Action event the code sets up the call to the web service using the text entered in the first TextArea:

Dim url As String = "https://api.funtranslations.com/translate/klingon.json"

Dim param As String = "text=" + EncodeURLComponent(EnglishArea.Text)

KlingonAPI.SetRequestContent(param, "application/x-www-form-urlencoded")
KlingonAPI.Send("POST", url)

In the KlingonAPI URLConnection object, add the ContentReceived event. This code grabs the translated Klingon text from the JSON and displays it in the 2nd TextArea:

Try
  Dim json As New JSONItem(content)
  Dim contents As JSONItem
  contents = json.Value("contents")
  Dim klingonTranslation As String = contents.Value("translated")
  KlingonArea.Text = klingonTranslation
Catch e As JSONException
  MsgBox("Error processing API call. Content=" + content)
End Try

You can also add the Error event and have it display an error in case there’s a problem with the API call:

MsgBox("API Error: " + e.Message)

And that’s all there is to it.

You can download the project from here: KlingonTranslator Project, just remember some things can’t be translated!

I’ll leave it up to you to implement a Klingon to English translator, although you may want to make that a mobile app in case you are ever teleported to the bridge of a Klingon vessel.

Qapla’

For English systems you don’t have to do anything. By default the Edit menu text is “Edit” so macOS will find it and automatically add “Start Dictation” and “Emoji & Symbols”. Should you not want them to appear, you can change the text so that it is “Edit ” (with an extra trailing space).

For non-English systems you will need to provide a Dynamic Constant to use in place of the hard-coded text of “Edit” on the EditMenu. This dynamic constant needs to have the appropriate translation for Edit as required by macOS.

Here’s how you can set this up for a variety of languages.

Added a public Dynamic Constant to App:

Then use it in the menu:

When you run the project with French set as the primary language you will see “Démarrer Dictée” in the Édition menu:

Do the same thing for other languages you need. The easiest way that I found to determine the correct word was to change your System Language and then start a built-in Apple app such as Notes or Safari and make a note of what the “Edit” menu is called.

Download a project with the above languages in a Dynamic Constant.

Here are 5 basics to consider when localizing your app:

1. Different Word Lengths
Some languages, such as German, have longer words than other languages like English. When designing your UI controls, you’ll need to account for this. A common way is to make the buttons large enough to accommodate the longest text.

You could also add code to the UI controls to have it resize itself if the localized text would not fit. But resized controls can also affect other controls on your layout, so a system like auto-layout can also help greatly to ensure that your UI adjusts itself appropriately when the text changes.

2. Don’t use Google Translate
Find someone that natively speaks both languages to do your translation. Obviously, you will need more than one person if you are translating to many languages.

Google Translate has its uses, but it’s translations often have unusual (or wrong) words and phrasing. So even though the text will be in the localized language, it could still remain difficult for native speakers to understand.

You don’t want your translations to say “Throw me down the stairs my shoes.” when it should say “Toss my shoes down the stairs to me.”

3. Don’t forget about dates
Date formats vary, so be sure to consider how they are displayed. What is the date for 3/7/14? Is it March 7th, 2014 or July 3rd, 2014? For internal dates that are not displayed to the user, you should use a standard format, such as SQL Date: YYYY-MM-DD.

When displaying dates, you should always use the user’s OS settings. This applies to both short dates with just the numbers and long dates where the month and day are spelled out.

And remember the position of each date component. Some places might use “March 7th, 2014”, but others would use “7 march 2014”.

4. Numbers
As with dates, numbers are also displayed differently. Not all countries use a “.” as the decimal separator. Not all countries use “,” as the thousands separator. The display of 3456.78 could be “3,456.78” is one location, but “3 456,78” in another.

Ask the operating system for the values specific to the user’s system settings.

And as with dates, when using numbers internally always use a standard and consistent format so that you can read them correctly regardless of the localization.

5. Currency
This trend continues with currency. Don’t presume that “$” is the currency symbol. As above, you should ask the OS for the specific currency symbol. And when storing currency values, do not include the currency symbol as that could make doing math on the values more difficult.