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.[Read More]
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.
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.
To set up a price drop campaign:
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.
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:
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.
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.
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.
Jean-Claude describes localization in detail and proves there’s nothing to be scared of.
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.
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.
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:
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 Distimo1, 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.
1Distimo MEF Mobile App Ecosystem Sept 2013.
Some of the most exciting feedback that we’ve heard from developers is the fact that paid apps are a bigger percentage of total downloads on the Amazon Appstore than on Google Play. The latest great example is from Zinkia in Spain.
Zinkia is the creator of entertainment brands such as Pocoyo, a popular kids' character in Spain. Zinkia's goal is to develop global brands on all mobile app platforms.
When we told Zinkia that Amazon Appstore was already available in Spain, they immediately decided to submit their “Pocoyo” apps. One of the factors in their decision was the low cost to get from other Android marketplaces to the Amazon marketplace. However, they didn’t have high expectations in terms of revenue because of how new the Amazon Appstore is in Spain.
Zinkia was pleasantly surprised, however, when they saw the first results in March: in absolute terms, their paid apps made almost the same money on Amazon Appstore as on other Android platforms.
Compared to other Android application stores, for Zinkia, the Amazon Appstore has a much higher proportion of paid downloads, which accounts for this positive result. When downloading “Talking Pocoyo” from Tienda Apps, for example—a game with free and paid versions—customers purchased the paid version more than 15% of the time, compared to less than 1% on other Android app stores. So while Amazon Apps is still ramping up the total volume of downloads for Spanish developers, it already leads to impressive paid vs free app downloads.
Why do customers using the Amazon Appstore purchase paid apps at a higher rate than in other Android app stores? It’s because of the Amazon Appstore includes popular Amazon features like personalized recommendations, Customer Reviews, 1-Click payments and the fact that Kindle Fire devices purchased from Amazon are pre-registered.
TashaKim, Public Relations Manager, GAMEVIL, is our guest blogger for this post.
GAMEVIL is a leading mobile games publisher and developer headquartered in Seoul, Korea,with branches in Los Angeles, California, and Tokyo, Japan. GAMEVIL has expanded their global presence over the years through an ambitious lineup of internal and third party titles localized in eight different languages. GAMEVIL specializes in mid-hardcore mobile games and prides itself on their strong following of players who enjoy their RPG-based titles.
At GAMEVIL,we believe that localization is one of the most important steps during post-game development. Correctly localizing a product not only promotes accessibility toa wide range of players across the world but also establishes global brand awareness. Our games are localized in over eight languages through in-house translators as well as third-party companies. Due to the geographical closeness and cultural similarities, our games are heavily popularized in Asia. Japan, in particular, holds a high percentage of downloads and monetization. We believe this is in part due to the localization of our content into the Japanese language and culture.
Below are a few guidelines we learned in our experiences localizing to Japanese as well as other Asian countries that may help other developers:
Translation is Not Localization
There are countless outsourcing companies overseas that will offer a literal translation of the language, but because so many RPG titles hold a rich and deep storyline,a literal translation would render the story awkward, bland, and lose the interest of the player. At GAMEVIL Japan, we translate the game internally and often outsource to third-party translators as well. Then, we initiate a second round of in-house translations. This portion focuses more on the cultural nuances and idioms that might not have translated seamlessly.
Understanding the Culture: The Importance of Physical Presence
We believe that it’s not enough to simply localize into a language through text, but that a full immersion is the best way to understand a culture and what is relevant in the region. The staff members at our Tokyo office are Korean/Japanese who have a sound comprehension of the social and cultural nuances. As similar as East Asian cultures may seem, there are still dynamic differences linguistically between countries that require sensitivity and attention. Once a literal translation is done, GAMEVIL Tokyo will go through a proofread, cross checking the text of the original document and implement any necessary changes. This process usually consists of omitting phrases that are irrelevant and adding text that will vibe well with the Japanese gaming culture.
The Importance of Proofreading
One key aspect that remains an extreme priority in our localizing is in the final steps of proofreading. We check each line to make sure that the meanings and expressions held behind each word and phrase flows seamlessly. The last thing that you would want is to make your game seem foreign to native gamers. We will usually have at least three rounds of thorough review before the translation is released to the public.
Localize the Entire Experience
One common misconception is that localization simply ends with the text, but localization often applies to the whole game. We cater each game according to regions. For many of our titles, we will implement Global, Asian, and Korean servers to create an experience that is relevant and user friendly. In addition, we take a user’s environment into consideration. For many Japanese users, gameplay will take place during a commute on the subway or bus in addition to heavy gameplay at home. We try to focus on quick loading times to encourage gameplay during short sessions. For our strong RPG and sports titles, we create short side quests such as the Abyss system in ZENONIA® and Exhibition Mode in Baseball Superstars® that can be enjoyed in short sessions. Japanese users are also big gamers and enjoy the anime RPG-style of many of our titles. With an immersive storyline and high-quality visuals combined with a well-polished text, our titles have seen success in terms of downloads and purchases in Japan.
We want to put out a product that seems indigenous to the users as they play the game. Our end goal is to create a game that transcends language and cultural boundaries that can be enjoyed by people regardless of age,gender, and ethnicity.