Globalizing Your Bluemix Application

Posted by steveatkin in Bluemix, Globalization, Language Translation

Developers often struggle with how to quickly translate their cloud applications without having to hire professional translators and wait around for their translated resource bundles to be returned to them. Well IBM Bluemix has a great new service called Globalization Pipeline that lets you translate your applications in minutes without having to leave the Bluemix dashboard. The Globalization Pipeline service is a great time saver and enables you to rapidly reach out to new markets.

Globalization Pipeline Service

The most exciting aspect about the IBM Globalization Pipeline service is that it is fully integrated into IBM DevOps Services, so you can quickly invoke the service from the Build & Deploy tab in IBM DevOps Services. This lets you continuously build your application in the cloud and have your translation automatically updated whenever a change in your English resource bundles is detected.

For those developers that wish to manage their translations more granularly, you can manually upload your English resource files in the Globalization Pipeline service dashboard and then select the languages that you want your content translated into. When the translation is complete you can retrieve the translation through the service’s RESTful APIs, programming SDKs, or manually download the files from the service’s dashboard. The choice is completely up to you and enables you to support both static and dynamic forms of translation. Here are a links to the Java and Node.js SDKs.

As you use the Globalization Pipeline service you may wish to make edits and changes to the machine generated translations for things such as your company name and unique terminology used in your application. This is really simple to do in the Globalization Pipeline service. You can use the service’s dashboard to directly edit your translations and persist them in the cloud so you never have to worry about losing your edits. You also don’t have to worry about accidentally overwriting your edits when you translate new strings, as the service only retranslates English content that has changed.

I encourage you to go and checkout the Globalization Pipeline service and let us know what you think. Here is a link to a YouTube video to help you get started with using the service. We would love to hear about new features and functions you would like to see and how the service has helped you build globalized applications on Bluemix. If you run into trouble or just need a little help getting going with the service feel free to reach out to me and I can jumpstart you on your way.

To get started with the Globalization Pipeline service:

Select and bind the service to your Bluemix application just like any other service on Bluemix.
Once the service is bound to your application you can open the service’s dashboard and upload your resources or you can configure the service to automatically upload your resources from IBM DevOps Services.
Globalization Pipeline Service Dashboard

IBM DevOps Services Build and Deploy
After your content is translated you can retrieve the content dynamically using one of the SDKs or through the RESTful APIs. If you wish to have your content in a file, then you can download the file from the dashboard.

I hope this short blog post helps you get started with the Globalization Pipeline service and enables you to quickly reach the global market. For more information on the Globalization Pipeline service checkout the documentation.

How to Use the Internationalization APIs in Node.js on IBM Bluemix

Posted by steveatkin in Bluemix, Globalization, Node.js

This post is to help you get started with using the new ECMA 402 Internationalization APIs in Node.js. In an earlier post I showed you how to query the Accept-Language header setting to determine the appropriate language to use in your Node.js APIs on IBM Bluemix. Now that we have the appropriate language and or locale we can use that value to help us properly format numbers, dates and times, and collate words.

This is an important aspect as the formatting of numbers, dates and times, and sort orders vary greatly across the world. For example in the United States we typically format dates in mm/dd/yy order while in France dates are formatted in dd/mm/yy order. By using the Internationalization APIs, dates and times will automatically be correctly formatted without you having to research all the various formats used across the world.

As of release 0.12.0 Node.js includes the Internationalization APIs. With that being said, only the English United States locale is included by default. To enable the Internationalization APIs to work in other languages and locales you need to include the optional locale data. The additional language and locale data comes from the International Components for Unicode project. Fortunately, it is very simple to add the additional locales to either a local instance of Node.js or Node.js running on IBM Bluemix and all you need to do is follow these steps:

Add the full-icu package to your package.json file. This will install the full-icu package into your node_modules directory. Alternatively you can install the package globally by running npm install -g full-icu@1.0.2
{
“name”: “ParseLanguage”,
“version”: “0.0.1”,
“private”: true,
“scripts”: {
“start”: “node ./bin/www”
},
“dependencies”: {
“body-parser”: “~1.13.2”,
“debug”: “~2.2.0”,
“express”: “~4.13.1”,
“request”: “^2.60.0”,
“accept-language”: “~2.0.16”,
“full-icu”: “^1.0.2”
}
}
Invoke node with the icu-data-dir=node_modules/full-icu. In this example I am modifying the start command used in my Express project to include the icu-data-dir.
{
“name”: “ParseLanguage”,
“version”: “0.0.1”,
“private”: true,
“scripts”: {
“start”: “node –icu-data-dir=node_modules/full-icu ./bin/www”
},
“dependencies”: {
“body-parser”: “~1.13.2”,
“debug”: “~2.2.0”,
“express”: “~4.13.1”,
“request”: “^2.60.0”,
“accept-language”: “~2.0.16”,
“full-icu”: “^1.0.2”
}
}
Use any of the Internationalization APIs in your code and pass in the language and or locale from the client side request. In this example I am parsing the Accept-Language header and determining the best match against the language and locales that my application supports. Once I have determined the best match I use that value in the Intl.DateTimeFormat API.
var supportedLanguages = [‘en-US’, ‘fr-FR’, ‘es-ES’, ‘de-DE’];
acceptLanguage.languages(supportedLanguages);
// Get the requested client side language
var requestedLanguage = req.headers[‘accept-language’].toString();
var bestLanguageMatch = acceptLanguage.get(requestedLanguage);
var dateStamp = new Intl.DateTimeFormat(bestLanguageMatch).format(new Date());

I hope this post has shown how easy it is for you to use the ECMA 402 Internationalization APIs in your Node.js project.

Adding a Custom Domain Dictionary to Watson Language Translation Service

Posted by steveatkin in Bluemix, Language Translation, Watson

The use of machine translation has become nearly omnipresent across many applications to help users understand content in other languages. Even though machine translation does a great job at giving you a gist of the meaning there are occasions where specialized technical terms are inappropriately translated. To help you manage these situations you can apply your own custom dictionary during machine translation. Recently the Watson Language Translation service on Bluemix introduced domain customization to let you tune your machine translated results.

In this post I am going to explain how you can quickly create your own TMX custom dictionary. If you are unfamiliar with translation memories and the TMX standard you can find more information here. Before we get started though there are a few key points to remember:

Not all translation models can be customized.
The size of your TMX file must be less than 50K.

To upload your translation memory TMX file take the following steps:

Call the Watson Language Translation API to get a list of all the Watson Language Translation models to see which ones support customization. Use the Watson Language Translation credentials that you obtain after you bind the Language Translation service to your Bluemix application and replace the username and password in the API with your values.
curl -u “username”:”password” \
“https://gateway.watsonplatform.net/language-translation/api/v2/models”
Push your custom dictionary to the Watson Language Translation service. Here is a sample TMX file that you can use to help you get started building your own. In this file you will find that I am customizing the English to French domain model. After you upload the TMX file it may take a few minutes before you can start to use your own customized model. After you make this call you will receive a model id as part of the response. Be certain to write down this model id as you will use it later when translating your content. If you don’t use the model id when calling the translation API, then your custom dictionary will not be applied.
curl -u “username”:”password” \
-X POST \
-F base_model_id=en-fr \
-F name=”custom_glossary” \
-F forced_glossary=@glossary.tmx \
“https://gateway.watsonplatform.net/language-translation/api/v2/models”
To check and see if your custom dictionary is ready for use call the API and check the returned status. If the returned status is available, then you are ready to start to use your custom dictionary. Be certain to replace the model-id with your model id value that you obtained in the prior API call.
curl -u “username”:”password” \
“https://gateway.watsonplatform.net/language-translation/api/v2/models/model-id”
To have the Watson Language Translation service use your custom dictionary be sure to specify the model id during API calls.
curl -u “username”:”password” \
-X POST \
-d {
“model_id”: “model id”,
“text”: [
“When you make a post about Cloud Computing be sure to use the correct hashtag”
]
}

I hope that this posting helps you get started with building your own custom dictionaries so that you can supplement the great results you already get from using Watson Language Translation on Bluemix.

Tags: Bluemix, Watson Language Translation

How to Obtain the Accept-Language HTTP Header With IBM API Management

Posted by steveatkin in Bluemix, IBM API Management

In this post I am going to explain how you obtain the client side HTTP Accept-Language setting for APIs built with IBM API Management on Bluemix and use the setting to determine the appropriate language to use in your API. I have created some sample code on IBM Jazz Hub that you can use as a basis for adding this capability to your own APIs.

When you are designing globalized APIs that are deployed using IBM API Management you need to take a few specific actions during the assembly step to ensure that the HTTP Accept-Language header field is properly forwarded to your implementing API.

By default IBM API Management does not forward and map all HTTP header fields to your underlying implementing API. To forward the Accept-Language field from the HTTP header perform the following steps:

From the Overview tab select Request from the left navigation and then add the Accept-Language field from the available HTTP header fields.
Select Accept-Language
From the Implementation tab establish a connection to your underlying implementing API.
Establish API Connection
From the Define tab under Request Headers select Accept-Language.
Select Accept-Language Field
Frome the Configure tab select Select Values and then select the Accept-Language field to map the value to your underlying API implementation. After you complete this step you will be able to access the Accept-Language setting from your API.
Map Accept-Language HTTP Header Field

Once you have the Accept-Language field being forwarded to your API you can compare that value with all the supported languages in your service. To help make the task of selecting the most appropriate language to use in your service you can use the accept-language Node.js package. In my example service I support three languages: English (en), French (fr), and Spanish (es) with the default being set to English.

I hope this helps you get started building globalized APIs with IBM API Management on Bluemix.

Tags: Bluemix, IBM API Management

Building a Secure Service With IBM API Management on IBM Bluemix

Posted by steveatkin in Bluemix, IBM API Management

Developing secure APIs with IBM API Management and IBM Bluemix is really simple and in this blog post I will provide an overview of the key steps you need to follow to get your secure APIs published in a custom catalog on Bluemix for other developers to use.

Creating APIs with IBM API Management eliminates many of the mundane tasks associated with creating APIs. For example, with IBM API Management you can finely manage who can subscribe to and view your APIs without having to write any of this code yourself. IBM API Management also provides automatic metering, analytics and versioning control so you can easily see how your APIs are being used without you having to create specialized code yourself.

One of the big benefits to using IBM API Management involves security and access control. Prior to IBM API Management developers often had to implement their own security and access control mechanisms for their APIs. With IBM API Management you don’t need to worry about doing this as IBM API Management takes care of all those details. You only need to focus on developing the API.

In this blog post I am going to explain how to secure and expose APIs from a Bluemix application via IBM API Management. To do this we will use an existing application called Stock Quotes. You can find the source code to the application in the Stock Quotes project out on IBM DevOps Services. The Stock Quotes application contains a number of APIs that are used to get stock symbols, stock quotes, and company news. I will be walking you through the general process of making APIs available using IBM API Management and if you want to you can go ahead and fork the project and try out all of the APIs and publish them to your own custom catalog on Bluemix.

The Stock Quotes application uses other Bluemix services: AlchemyAPI, MongoLabs, and IBM Insights for Twitter. So be sure to bind these services when you deploy the application on Bluemix. Additionally, the Stock Quotes application requires that you establish a Mongo database with all the companies and corresponding stock symbols that you wish to be able to lookup. Be sure to read through the project description to understand the requirements and necessary configuration for using the Stock Quotes application, see README.md.

Create Basic authentication credentials for accessing your APIs. We will use these credentials to establish a secure connection from IBM API Management to the internal implementation of the APIs. These credentials will not be given out to end-users. IBM API Management will automatically generate end-user credentials for you as developers bind your APIs to their applications.
Make sure to set the SERVICE_ID and SERVICE_SECRET environment variables with the Basic authentication values you generated. In each service we will check to make sure that the credentials are valid. For example, this code fragment shows a check to make sure that the header contains the correct credentials.
Checking Basic Authentication Credentials
To make our service secure we will reject calls over HTTP and only allow calls over HTTPS. For example, this code fragment shows HTTP calls being redirected to HTTPS.
Redirecting HTTP Call to HTTPS
Publish the application to Bluemix.
From the Bluemix service catalog create an instance of IBM API Management.
Launch the IBM API Management dashboard.
Create an API Plan for the services you will expose. For example, you could create a Basic Plan for accessing your services.
IBM API Management Plan Definition
Configure a route to your API, the version, and type of security for accessing your API. As I said earlier IBM API Management will take care of generating credentials to access your services. By default IBM API Management will use client id for security. You can go ahead and change the default settings to include client id and client secret if you wish to have a greater level of security.
API Security Settings
Define the API access method, request parameters, and response for your API. For example, this API uses the GET method and has one required parameter.
Defining the API Method
Connect the public API route to your internal secure API. In this example we are going to use the compose option from IBM API Management to connect to one of the APIs in the Stock Quotes application. The key point to remember is that you need to fill in the Basic authentication credentials that you generated earlier and make sure the connection is using HTTPS.
Secure API Connection
Map the input request parameters from the public API that you are exposing to the request parameters of the internal implementation in the Stock Quotes application. For example, I am mapping the symbols parameter from the public API to my internal implementation that will handle the request.
Mapping API Request Parameters
Map the internal API response to the public API. With IBM API Management you can select which elements to return from your internal API implementation to the public API. For example, I can select a subset of elements to return.
Mapping API Response
To start the process of making your API available to others you need to add the API to the plan you created earlier. For example, here I am adding the stock news API to my plan.
Adding the API to a Plan
The last step in getting your APIs exposed is to publish and stage your plan by selecting your subscribers and publishing the plan. For example, here I am selecting a few Bluemix organizations that I wish to expose my APIs to.
Exposing and Publishing Your APIs

After you have published your APIs you can find them under the Custom APIs category. For example, here you can see all the Stock Quotes APIs that users can select and bind to their applications. When a developer binds one of your APIs to their application the credentials for accessing the API will be automatically generated by IBM API Management and will be accessible from the VCAP environment variable.