This article provides basic guidance to help you plan and implement multiple language support in your Android apps.
Android has excellent features that make implementing and managing multiple languages easy, and you should take full advantage of that in your apps.


Supporting multiple languages is the most important aspect of localisation.
Localisation and language support:

Localisation refers to the adaptations required in an app's user interface to support users in different geographies—referred to as locales.

Locale support includes


  Supporting multiple user languages, including different character sets (accented
    characters, special symbols, punctuation)

  Presentation differences like number seperators and date and time formats

  Address formats, sorting orders, and time zone and calendar differences

Multiple language support is therefore not the whole story of localisation, but it is an essential first step. Depending on what functionality your app offers, it may be enough. Also, multiple language support depends only on Android features, whereas other aspects of localisation (formats and sorting orders for example) depend on Java language mechanisms.

From a developer perspective, the essential requirement for implementing multiple language support is to provide translations into the languages you intend to support for all strings that your app will display to users.


Why bother with translation?

Some developers take the view that "most" users are "tolerant" of English-only apps.

However, an English-only app does not meet the quality level required for submission app stores in non-English speaking European countries.

Supporting multiple languages is therefore a prerequisite for increasing the number of potential users your app can reach. 


Android support for multiple languages:

Android adopts a resource-driven approach to presenting locale-specific app content. To support multiple languages, developers supply language-specific resource files containing translated strings as part of their app source code. At build time, the Android build system generates compact binary representations of all string resources, which are packaged into the final app package.

Android takes care of switching-in the appropriate language strings based on the user's settings.

The essential developer tasks are therefore to:


  Provide translations for all strings, or subsets of them, that the app presents to users

  Make the translations available in language-specific resource files at build time

  Ensure that default resource files are provided in case the user language is not one of
    the languages you support.

In Android terminology, the process of separating resources from code and supplying them to the build system in resource files is referred to as "externalization".

As a general rule, you should always take advantage of Android's externalisation facilities, and never hardcode strings (that will be displayed to the user), images (that you may use as backgrounds for UI elements), icons (that launch app functions), or even sounds (for example alerts). Instead, follow Android's resource model.


Supporting multiple languages:

It's important that you serve all of your users, not just those in the biggest markets.

The following tips will help you plan and implement multiple-language support in your Android apps.
Tips 1—String file locations for Vodafone European countries

Use the table below to help manage string resources for multiple languages. Currently, the UK and Germany are the most active markets. Therefore, unless your app really is local to a single country (see Tip 10), you should aim to support at least UK English and German languages, in addition to your own language if different. You should also consider adding more languages in future app upgrades.

You must always support a default language by including a default strings file res/values/strings.xml,see Tip 2

 Market Region   Code Language Region          code String file Android Version
United Kingdom  UK English en_rGB res/values/strings.xml Since 1.5
Eire(Republic of Ireland) IE English en_rIE res/values-ie/strings.xml Since 2.3
Germany DE German de_rDE res/values-de/strings.xml Since 1.1
Greece GR Greek ei_rGR res/values-el/strings.xml Since 2.3
Italy IT Italian it_rIT res/values-it/strings.xml Since 1.5
Netherlands NL Dutch nl_rNL res/values-nl/strings.xml Since 1.5
Portugal PT Portuguese pt_rPT res/values-pt/strings.xml Since 2.3
Spanish ES Spanish es_rES res/values-es/strings.xml Since 1.5




Tips 2—Provide a default string file (and test your default support)

When your app runs on a phone set to a language that you do not explicitly support, Android will use the default strings file (and any other default resources) to display user visible strings.

Similarly, any strings required for display that are not defined in a language-specific strings file will be displayed from the default strings file.

If you don't provide a default strings file, and the phone is set to a language you don't support, your app won't launch (or will be shut down if already running).

The same thing will happen if you omit any string that is required for display from the default strings file.

Always test your app in the default language to ensure that it runs correctly without language-specific resources.


Tips 3—Understand resource switching and locations

Language strings are supplied in a strings.xml file (see Tip 1 for naming details). The default strings.xml is always located in the res/values folder. Translated strings should be supplied in a strings.xml file located in a language specific res/values-<LANGUAGE CODE> folder, one folder (and one strings.xml file) for each language you support.

Android language switching is based on the phone language the user sets from the Settings menu. Note that the languages available depend not just on the Android version, but also on the phone model, and the manufacturer's provision for the local market too.


Tips 4—Be prepared for runtime language changes

If the user changes the phone's language setting while your app is running, the following happens:


   onDestroy() is called for your currently running Activity

   onCreate() is called for your currently running Activity

In other words, your Activity is stopped and restarted.

Android calls onSaveInstanceState() to save your Activity's state before onDestroy() is called. This enables you to restore state when your Activity restarts. Your onCreate() method should therefore call onRestoreInstanceState() to restore the app state. This enables you to handle the restart seamlessly.

 
Tips 5—Useful common accents and special characters

The most obvious written differences between European languages are accents and other special characters. To display translated strings correctly, you must create them correctly in your resource code. Even the list of localisable European languages presents this basic problem, for example:


  Spanish is written Español, and includes a tilde accent

  Portuguese is written Português and includes a circumflex accent

Special characters include:


  Speech-, exclamation-,and question-marks used in Spanish, respectively « and », ¡ and ¿

  German ligatures including ß (not to be confused with Greek lower-case beta β)

  The ª and º superscripts used in Italian, Portuguese, and Spanish for ordinal numbers

The HTML5 character reference table provides a convenient list of all the special characters you are likely to need in European language strings.

It is not necessary to generate these characters from the keyboard; use Unicode or HTML encodings directly in your string resources (see Tip 6).


Tips 6—Use HTML encoding to include styles and special characters (like accents) in your Android strings

The HTML5 table lists the Unicode codepoint for each named character entity.

For example, Caffè in Italian requires a grave accent above the "e", Unicode codepoint U+000E8.

You can use the codepoint to create a Java literal \u00e8 (4 digit hexadecimal number); or you can use the HTML character entity in decimal format &#232; (232 is the decimal conversion of hexadecimal E8).

Note that you cannot use the HTML named character entity &egrave; (the Android resource compiler rejects it).

For example, the following string defined in strings.xml:

<string name="caffe">Did you say <b>Caff&#232;</b>, or was that <i>Caff\u00e8</i>?</string>

builds and displays as:




Note also the use of HTML markup in the strings file for simple styling—see Find out more, below.


Tips 7—Rewrite strings to make translation easier

Translation can cause unexpected effects. A common problem is that string length for equivalent text varies significantly between languages, which can upset your layout.

Another is that some phrases just do not translate easily. Keep your language style simple. If a phrase is awkward in translation, try rewriting it in your own language to avoid the awkwardness.

Also, although it's not specifically a translation issue, avoid quantity formulations in your displayed text if you can. For example, "You have 1 new messages" will always read badly; but "You have new messages" reads well, even when there is only one message.


Tips 8—Swap translation tasks with others

Most developers won't have the language expertise required for translation, and many won't have the budget to buy in expertise.

Help yourself and others by harnessing the power of the Android developer community to swap translation tasks with developers in the countries you are targetting. Post in your favourite Android developer forums.


Tips 9—Think globally—even the most local apps can have wider appeal
Dutch users are probably are not interested in UK lottery results, but they may be interested in London Tube information, Spanish football results, Italian Slow Food events, and so on.

So even if your app depends on specific local content, it may still appeal to users in other countries.

Think globally, and your app may have a bigger market than you realised.


Find Out ....

Floating Notifications (Full) v1.1 Apk Download Free

                                      Floating Notifications (Full) v1.1 Apk | 570 KB
                                                  Requires Android:3.0 and up
                  Floating Notifications is a new and intuitive way to view your notifications!


App Review:

It can take a notification from any app and present it to you as a floating icon, similar to Facebook chat heads, but for any application. It even works in fullscreen mode (in Games, Youtube etc) and is fully customizable.

Themes:


  Any issues, requests or suggestions?

  Follow us on Twitter (@FNforAndroid)

  Like us on Facebook (http://www.facebook.com/floatingnotifications)

  Circle us on Google Plus (http://gplus.to/chatheads)

  Get beta access by joining the community (http://gplus.to/fnbeta)

  Or email us at support@iamrobj.com

Icon by FineTalent of XDA – http://forum.xda-developers.com/member.php?u=4841935

App integration:


  FN is not able to make notifications disappear from your status bar. An app cannot dismiss
    another apps notification.

  However, if you want any of your favourite apps to either make their status bar notification
    disappear when you dismiss the corresponding Floating Notification, or vica versa, you
    can point them to this page where they can add Floating Notifications integration:

Halo:

This is NOT Halo. There are no popups of full apps and nor will there ever be. If that is what you are after unfortunately you will not find it here.

What’s in this version:


  Added option to save remember position on restart

  Added backup/restore option for settings (requires SD Card permission)

  Accessibility type is now configurable

  Max width is now equivalent to screen width (still doesn\’t work above 600px yet)

  Fixed pinned icons not resizing when icon size is changed

  Fixed some UI issues



Here is the link for Download........................