Announcing New Alexa Skills Kit Developer Tools to Help You Deliver Visuals on the Latest Echo Devices, More Languages, and Personalization

Developers can now use the Alexa Skills Kit to build skills for Hindi speaking customers in India using the new Hindi language model. This blogpost describes how to update your existing skills model and Lambda functions to support the Hindi(IN) model. 

Este tutorial muestra como agregar soporte para Español de los Estados Unidos de América "Spanish (US)" a tus skills existentes. Adicionalmente, te muestra como usar el ASK (Alexa Skills Kit) para que Alexa responda en función a el modelo de lenguaje.

This tutorial will show you how you can add support for Spanish (US) in your existing skills. It will also show you how you can use ASK to enable Alexa to respond based on locales.

This tutorial will show you how you can add support for the Portuguese (BR) model for your existing skills. It will also show you how you can use ASK to enable Alexa to respond based on locales.

In this post, I’ll be covering the steps to review before you should consider selling your apps internationally, including API availability, localization, pricing, and reviewing local feedback.

As a mobile app developer, you are probably always on the lookout for ways to increase your app’s visibility. Sometimes a good, old-fashioned sale is all it takes, and Amazon’s Developer Promotions Console (DPC) now gives you the ability to specify when you want to discount your app or in-app items. As an added benefit, promotions set up through the DPC will be featured automatically on the Appstore Deals Section of Amazon Appstore in the US and Germany, if appropriate.

The DPC makes it quick and easy to discount the list price of your apps and in-app items, perfect for promoting an update, taking advantage of a holiday or special event, or conducting price elasticity tests. You can specify in the DPC when and where these discounts are available, activating them over time in one or more marketplaces, or at a single instant worldwide. For example, you might want Amazon to discount your app 50% to promote the most recent update, or offer certain in-app items for free during a limited time. These promotion “campaigns” are a snap to create.

Get Featured Merchandizing on Amazon Appstore Deals

Once your price drop promotion is live, it will automatically feature in merchandizing on the Appstore Deals section of the Amazon Appstore in the US (and Germany, when applicable) to help drive traffic to your app.

Create a Campaign

To set up a price drop campaign:

1. Log on to the Amazon Developer Portal
2. Click the APPS & SERVICES tab and select Promotions
3. Click the Price Drop button, and
4. Choose the type of campaign you would like to create

A single campaign can discount one or more mobile apps, mobile in-app purchase items, or PC and Mac apps at a time. Every campaign type allows you to set a start and end date, but you have even more control over mobile discounts.

Fine Tune Timing and Availability

For example, you might choose to discount an app only on Amazon’s main marketplace in the US, kicking off the promotion at one o’clock in the afternoon. You have the option of using fixed or relative start and end times. Fixed means the campaign will go live simultaneously across all marketplaces you select, measured in Pacific Time. Relative means start and end times will be adjusted to a reference time zone local to each marketplace (see below for the time zone used in each case).

To fix the campaign timing across all marketplaces, click the radio button labeled Start at a single global instant (relative to PDT). To stagger availability by marketplace, click Start at the same local time in each selected marketplace.

This setting applies to start and stop times both, which you can specify only once per campaign. If you want a promotion to be active at different times for different marketplaces (but not necessarily simultaneously, as with fixed), create a separate campaign for each marketplace.

You can only activate a campaign in marketplaces where your app or in-app item is available. If the specific items you want to discount are not available in China, for example, you will not be able to select amazon.cn as a target marketplace for the campaign. Publish to any of these marketplaces and they become valid targets for your promotional campaigns:

• amazon.com               time zone: America/Los_Angeles (PST/PDT)
• amazon.co.uk              time zone: Europe/London (GMT/BST)
• amazon.de                  time zone: Europe/Berlin (CET/CEST)
• amazon.fr                    time zone: Europe/Paris (CET/CEST)
• amazon.co.jp               time zone: Asia/Tokyo (JST)
• amazon.ca                   time zone: America/Vancouver (PST/PDT)
• amazon.cn                   time zone: Asia/Shanghai (CST)
• amazon.es                   time zone: Europe/Madrid (CET/CEST)
• amazon.it                    time zone: Europe/Rome (CET/CEST)
• amazon.com.br           time zone: America/Sao_Paulo (BRT/BRST)
• amazon.com.au          time zone: Australia/Sydney (AEST/AEDT)

Define Discount and Confirm Campaign Settings

After you have set start and stop times for your promotion, click Next to define the discount amount, then click Next again to preview the campaign settings. If everything looks good, click Submit to save the campaign and indicate it should be launched when the time comes.

Refine Your Mobile Promotional Campaigns

The Developer Promotions Console offers a self-service interface for scheduling temporary discounts on your mobile apps and in-app items sold through Amazon. It provides the ability to set up promotions to launch simultaneously around the world or at the same hour of the day in multiple marketplaces. These discounts can be made available everywhere or limited to specific geographic regions. Promotions you create are featured automatically on the Appstore Deals section of Amazon’s Appstore in the US and Germany, when appropriate.

Use this flexibility to refine your promotional campaigns and tailor them to your specific needs. Get more information about the Developer Promotions Console online, or simply log on to the console to look around and give it a try.

-peter (@peterdotgames)

Most people prefer to use apps in their own language, but many developers consider app localization a dark art.  Where do you start?  How will your code change?  Who will translate?  If you’ve never localized an app before, the process can be intimidating.  It’s a critical first step, though, if you want to reach a worldwide audience.

Here guest blogger Jean-Claude Cottier demystifies app localization.  A veteran game developer and architect, Jean-Claude has spent 18 years developing 3D technology for AAA titles and mobile apps.  He has released many apps in the global marketplace through Ovogame, an indie studio he founded.  In this practical guide, Jean-Claude explains how to plan for localization, track and organize what will change, support different languages in code, and find translators to localize your assets.

Localization: a Winning Solution

Thanks to digital distribution, we now live in a global market and a lot of our potential customers simply don’t speak English. Having your applications localized will increase their global reach and will open new opportunities for your business. You’ll be more likely to find local partners and distributors interested in your products. Supporting more than one language isn’t a complex task once you’ve setup everything and streamlined your development process. Most of Ovogame’s applications are localized in many languages (English, French, German, Spanish, Italian, Russian, Japanese, etc.). It’s well worth it for us as we generate about 45% of our income from non-English-speaking territories. In this article, we’ll give you directions and tips about the technical side of localization. At Ovogame, we are using our own multiplatform engine (Fire OS, Android, iOS, Windows, OSX, BB10). As it is possible to use these techniques on all systems, we’ll stay as platform-neutral as possible.

No Text in Your Code

The best way to handle localization is to think about it from the start of your project. You shouldn’t treat your primary language (English) differently than the other languages supported by your apps. English may be set by default, but that should be the only difference with the other languages.

The golden rule is to NEVER have any text hard-coded inside your source code. Instead, it should all be stored in an external file (like any other data). Supporting different languages means creating different files per language and loading the correct one.

As you can’t have any actual text in your code, the best way is to handle them with keywords. For example, if you want to display a greeting message like, “Hello world,” you could use the keyword GREETING instead. Your code could look like this:

String message = Translate(“GREETING”);

	DisplayText(message);

The function Translate returns the correct sentence to display. If the application language is set to English, it will return, “Hello world,” but if it’s in French, “Salut monde.” The function Translate needs a simple list of keywords linked to their localized sentence. It will scan this list and once the right keyword is reached, it returns the corresponding text. In practice, it’s wise to cache this string; there is no point to call Translate every frame.

Using keywords is very nice because you can still understand their meaning when reading your code. As they are proper strings, you can build some of them dynamically (mainly when they’re indexed: RATING_0, RATING_1 …) to simplify your code.

Using Excel or Open Office

We like to use Excel’s files to store all our localizations and there are many good reasons for this choice. Everyone can view and edit these files, so the persons localizing or proofreading your text will be comfortable with this format. You can add more information (extra columns and lines) and use different colors to help them. It’s also easy to provide links to images (often better than a long speech). Basically, Excel is a very practical tool for creating and managing all your localization.

The other great advantage is that your database is automatically created. The relationship between your keywords and their localizations is obvious: each line contains a keyword and its corresponding translation (stored in two consecutive cells). We need a way to extract this information so you can use it in your application. Excel’s files are complex and coding a function to read such a file format would be a lot of work. Thankfully, we don’t have to do this because it’s easy to convert them into a basic ASCII text file. If you are serious about localization, you should handle text files supporting two bytes per character. If you want to localize in Japanese or Chinese, you must support this anyway. It isn’t mandatory, but it would be a shame to not support it. Simply store your characters in 16 bits instead of 8 bits.

Before converting your Excel file, you might want to do a bit of cleaning first. You should remove all unwanted information and just keep the first two columns (keywords and localizations).

If you are using Microsoft Excel to convert your file, simply save it as a Unicode text (*.txt) file. This new file contains only ASCII characters stored on 16 bits. As the following picture shows, it’s a very simple format. You can use it directly in your application.

Remember that every ASCII character in that file is stored using two bytes (16 bits). The file starts with a magic number (one character: ASCII value 65279) that you can skip. A TAB character (ASCII value 9) is used to separate the keywords from their localization. A carriage return (ASCII value 13 and 10) is used to separate the different lines. As you can see, it isn’t difficult to code a little function to load this file into memory and create a linked list or lookup table of these keyword/localization pairs.

If you are using Open Office instead of Microsoft Excel, you can save your files as Text CSV (.csv) (*.csv) using UNICODE for the ‘character set’ option. The file format isn’t the same as the previous one, but you won’t have difficulties figuring out the differences by yourself.

Selecting the Correct Language

At this stage, you have a specific text file for each of your supported languages. You just need to load the correct one. A nice little feature is to automatically select the language used by the device. So, if the device is set to French, your application could automatically start in French. With most platforms, it’s very simple to find out the language set on your device. For example, with Android, you can simply call a function from your Activity class:

	Configuration config = getApplicationContext().getResources().getConfiguration();

	String lang = config.locale.getLanguage();     

The function getLanguage returns strings like en (English), fr (French), de (German). You should check the value of lang and if you don’t support that language, set it back to your default one (en in our case as we want English to be default). This string will be used to identify the current language during your application life cycle, so keep it safe. You can use these abbreviations (en, fr, de…) to setup a simple naming convention for your files.

With this convention, it’s simple to know which file to load. Also, you can find out dynamically if a language is supported by your application: simply check if the corresponding language file exists. This way, you can add new languages without changing a line of your code. It’s always a good idea to make your code as generic as possible and let the assets handle themselves (data-driven instead of code-driven).

If you are developing your applications for different platforms (iOS, OS X, Windows, etc.), you’ll find similar functions as getLanguage on all systems.

Localizing Other Assets

Sometimes, you need to localize more than just text. You might have textures containing some writing. You should use the same naming convention as before.

To simplify your code, you can dynamically create the names of your localized textures using a simple function:

	String name = LocalizeName("gameover", "png");

The function LocalizeName concatenates the current language and the extension (.png in this example). So, if the language is Spanish (es), the name returned will be gameover_es.png.

You might have some assets that need to be localized in some languages but not for all of them. For example, in France, we are comfortable using the Anglicism ‘Game Over’ (translating it would actually sound weird). It would be a shame to duplicate the default asset just to create a fake localized one (gameover_fr.png). Instead, the function LocalizeName could test if the file exists (it’ll need the complete path for that). If the file doesn’t exist, the function should return the name of the default file. For our example, in French, LocalizeName would return gameover_en.png.

Finding the Right People

You should work with native speakers for all your localization. Don’t ever use automatic translation tools (online software) like Babel Fish or Google Translate. The result is so bad that you are better keeping your application in English.

There are many online services where you can hire translators, like dystranslations.com and tethras.com. We haven’t used them, but they were recommended by fellow game developers.

We did find an alternative way to get very motivated translators. We ask our fans if they can do it. These people enjoy our apps and know them almost as well as we do. We develop a much closer relationship with these users than we would ever get from hiring someone via an online service. They are very keen on making the best localization. We send them beta builds so they can test if their localization is perfect. It really feels like they are part of the team.

Final Tips

Give your translators as much detail about your application as possible. If they can test a proper version (like our fans do), it is even better. The more they know about your application, the better they’ll localize it.

Be careful with the size of your UI (buttons, message box, etc.). Most English words are small compared to other languages. Usually, German words are very long and it might be wise to check if they fit in your UI as early as possible. It’s also useful to have a way to auto-scale your text, so you can be certain it will always fit inside a specific area (like a button).

Don’t hesitate to add formatting information inside your text. For example, “Chapter [NUM]” contains the tag [NUM]. We will substitute the proper index in code (Chapter 1, Chapter 2…). It’s very useful because for some languages, the formatting is completely different (in Chinese, it’s in the middle 第[NUM]章). Using this solution will remove most of the formatting problems.

There are many other aspects to be considered when localizing (fonts, testing, etc.), but that would be too long for this article. Hopefully, this quick overview has convinced you that the technical side of localization is accessible to anyone. It’s a simple way to increase the visibility of your application; you should do it.

Since the launch of Amazon Coins in the US in May, customers have already spent hundreds of millions of Amazon Coins, representing real dollars to developers, who still received their 70% revenue share. Check out our August blog post to read more about some of the results from developers so far.

Today, we’re extending Amazon Coins to the UK and Germany as well. As a thank you to existing and new Kindle Fire owners in the UK and Germany, customers will get free Amazon Coins deposited directly into their accounts so they can experience how easy it is to shop with Coins. Customers will be able to use Amazon Coins to purchase apps, games, and a broad range of in-app items in the Amazon.co.uk Appstore, the Amazon.de App-Shop, and on Kindle Fire.

Amazon Coins are immediately available to customers who pre-ordered the new Kindle Fire HDX 7” and Kindle Fire HDX 8.9”. Both devices are now available in the UK and Germany. This is a great opportunity for you to take advantage of Amazon Coins and the perfect time to submit your apps for the holiday rush. In 2012, we saw a 50% increase in the number of app downloads during Thanksgiving week as compared to an average week. During ‘Digital Week’ 2012, the week after Christmas, customers purchased and downloaded 600% more apps than any other week during 2012.

We have already seen developers like Halfbrick, PepiPlay, and textPlus benefit from customers using their Amazon Coins to try out and explore new apps and games. For many Indie developers, Coins has accounted for the majority of their revenue since Coins launched in the US.

If your app is available for sale for Kindle Fire in the Amazon Appstore, there’s nothing else to do. So submit your apps today and take advantage of Amazon Coins. For more information on making your apps available on Kindle Fire devices, check out these links:

1.    Create an account on the Developer Portal
2.    Download the Amazon Mobile App SDK
3.    Review the Kindle Fire development resources

Just in time for the holidays, millions of customers can now purchase Android applications from the Australian Appstore and Brazilian Appstore using their own local currency. Available in nearly 200 countries since May, the Amazon Appstore now allows developers to price their apps in Australian dollars or Brazilian reais, in addition to the other currencies already supported. There’s even a new localization option for Brazilian Portuguese so you can make your app that much more relevant to customers in Brazil. And, the Australian Appstore is also accessible to Kiwis, so customers in New Zealand can download the best local and global apps, too.

Being able to offer your apps for sale in the local currency of Australia and Brazil means less friction for customers in two of the most important global app marketplaces. Brazil is the largest app marketplace in Latin America and is growing faster even than the US, according to a recent report by Distimo¹, which also ranks the Australian app marketplace #6 in the world in terms of revenue. Despite Australia’s considerably smaller installed base, only the US, Japan, South Korea, the UK, and China surpass it for app purchases.

In addition, you can publish any Android app on the Amazon Appstore, which includes those running on Kindle Fire OS. In fact, more than 75% of the Android tablet apps we’ve tested just work on Kindle Fire without additional development. Publish your Android app on Amazon and it automatically becomes eligible to be featured on our web storefront and to be included in search results and recommendations shown on product detail pages. Once your app or game is available in our store, you can also promote its availability by linking to it directly.

So, don’t miss this opportunity to monetize your apps and games in time for the holiday rush. In 2012, we saw a 50% increase in the number of app downloads during Thanksgiving week as compared to an average week. During ‘Digital Week’ in 2012 (the week after Christmas), customers purchased and downloaded 600% more apps than an average week during the year. Submit your Android app to our store today and let us help you increase your international exposure in time for the holidays.