Background:
We are trying to localize apps for FR-FR, FR-CA, ES-ES, and ES-MX. We've created the correct localizable.strings and strings.xml files for both android and ios, respectively. All four look like they are supported by both OS.
Issues:
We are having issues testing that these are correct. For instance, there is the option in either OS to select French, but not French Canadian. When we switch the language to French and the region to Canada in an iOS device, it only changes the keyboard.
Questions:
How do we test these languages?
Do these languages ship with the phones that are bought only in that region?
Note that for Android, the language-country attribute doesn't necessarily need to exist in a real combination for it to still work. For instance, if you create a localization for the German language in Canada, it will still work even though probably no one made a phone for that particular combination.
When confronted with an unknown combination, Android will just cascade up to the less precise German language attribute for language-related localizations (assuming German is even present on the phone/apk) and cascade up to the less precise geographical-only attribute of Canada (assuming Canada-related attributes are even present on the phone/apk).
Unfortunately, I don't know enough about iOS to give you specific advice on that part of the question.
How could you test for localizations? At Google I/O last year, there was a presentation on a new Eclipse localization tool for testing your layouts on many different locales at the same time.
As another testing strategy, that would also help with iOS, aside from asking distant family and friends living abroad, or asking your own existing customers (if you have any), you could go on http://fiverr.com/ and pay five US dollars to someone French-speaking in Quebec to do a quick test of your app on their phone and send you phone screenshots of your app running on their device.
Depending on your budget and the geographical location(s) you're targeting, there must be many other web sites/services that could help you crowdsource (or hire mechanical turks for) such a task.
Related
I have an app that is live globally (both iOS and Android versions). I want to produce a localised version for India that has some Indian branding and slightly different colours (that's pretty much it!).
Is this possible?
How can I do it?
I would like of course to make sure that the Indian version follows the same feature updates as the global app.
There are two ways in which this can be approached :
Identify the country at app launch(I guess there are several ways to do it) and save it in the memory and create views/behaviour accordingly. Pros: This way you wont have to maintain different apps in your AppstoreConnect account. Cons: It would be too much work if your changes are minor or if you are sure you wont require the same changes for different country other than India in future.
Create an altogether new app and release it after restricting its country access to India on the appstore.Pros: No possible bugs from the challenges in identifying country at AppLaunch that might crop up in 1st approach.Cons: You will have to maintain different apps in AppstoreConnect account for this which is not scalable.
I would prefer 1st over 2nd as that would be scalable for different countries in the future too.
I want to know whether it is possible to translate any android application in any language.
Like all application is in English language can it is possible or any API available to convert it into other language.
Let's say example like in setting menu we have Wi-fi,Bluetooth,Call Setting,about phone etc.are in english language. so with the help of any translator can we convert it into any language?
I already go through this link http://android-developers.blogspot.in/2013/03/native-rtl-support-in-android-42.html
To translate an application to another language you need a human translator, that is, a human being knowing what the application does, knowing the target language, knowing the rules of translation to the target language (*), and preferably knowing the language that the application was originally developed in.
(*) For example, Polish software always says "thou, do this!" because otherwise it would have to know who is reading the text: a man, a woman, several women, or several persons including at least one man. Your translator must follow common practice for the target language (for example, it would be wrong to re-phrase Polish to use nouns instead of verbs).
If you have a human translator, you can translate the application. First, make sure that no user-visible text is hard-coded, and no phrases are composed programmatically. Then, you just let the translator translate the resources. Resources for different languages will reside in different directories of your project. But the translator must know the context of each phrase, know what the application does before showing a message and what it will do after a menu item is chosen. If the translation is poor, a native speaker may get puzzled and will never choose the menu item that he/she is looking for.
There are companies specializing in app UI translation. They will want your money and you will not be able to evaluate the quality of their job by yourself, but probably this is the best you can do. (PS do not forget to ask them what happens if you change/add one or two messages.)
This might help:
Google translate api:
https://developers.google.com/api-client-library/java/apis/translate/v2
I am trying to determine the best approach on Android for supporting multiple languages. I understand how resource folders work, and how they get selected when the activity loads and/or has a configuration change. I also have seen a technique of creating a new locale, assigning it as the default, and broadcasting a config change. This works. But I get the impression from this thread (https://groups.google.com/forum/?fromgroups=#!topic/android-developers/_ZGOTHwzl-w) and the answers from the google framework team this way of doing things is not recommended / supported. So my questions are:
What is the recommended way to support multi languages on the fly without sending the user to the OS menus for language selection?
Same question for keyboard input.
Finally, I see on my Motorola Xoom when I ask the Locale class for supported languages an impressive list. For instance, ja-JP, which I've tested and seen allows me to display Japanese chars. However there is no SIP for this language on the device. Can I download new keyboards to my platform in these cases? It just seems odd to me that the platform would support displaying many more languages than it could input.
Just leave the system do the work.
A user with a language and a keyboard selected in settings will just expect the same conditions from your app.
As far as I knew, there's no better approach as the strings.xml in the different values folders.
I have the patience to convert my strings.xml file and my HTML help files to other languages using Google Translation Toolkit.
However, the translations are not "100%" correct.
I speak German as well as English so used the Eng -> Ger translation for my strings.xml etc.
Some of the "gaffs" made by the translator were pretty bad.
So, is it better to have 1 language done well (ie English) or to also provide multi language support but for languages I have no idea about whatsoever.
I wanted to cover the "big boys" too such as Mandarin, Hindi, Japanese, Russian, etc but am worrying bad translations would make my app seem to be of a low quality.
Has anybody any experience and words of advice on the topic.
Many thanks.
Paul.
You should probably hire translator(s) which are very good at the English and target foreign language(s).
One of the most important things is that translator must understand usage, concepts and conventions of your application - know it and understand it. Otherwise, you will end up with grammatically correct but meaningless translations in context of your app - I can see this in a lot of cases since my native language is not English.
And, yes, your app will look "low quality" and "hostile" to SOME people if it has translations that are missing the point.
German and English belong to the same language family and Google has ample data for both. Any other language, especially those that are linguistically a lot more distant (Chinese, Japanese, Hindi), is translated even worse than German. I do not believe that native speakers of these languages can get ANY value out of a machine translation.
Using a machine translation shows your foreign customers exactly how much value you place on them: none.
Wow !.
It looks like a thumbs down then.
Like all things in life I suppose "compromise" is the winner.
My app basically has a single setup screen with about 15 strings and a few radio buttons, check boxes etc.
The games themselves are pretty obvious but underating the "gist" is better than no understanding at all.
I'll focus on getting the strings for the setup page "perfect" and add the HTML "help" screen translations with fingures crossed.
I am of the view that is one goes to a country one should at leasr learn some of the language. My experience is that the "natives" appreciate an "attempt to speak theor tongue" rather than simply assuming "they" should understand English. By the same philosophy, if the "main" points are translated well, I should at least earn a few more points for "having a go to respect their language and culture" by going through the translation process of "all supplied help text".
As I say, it is a tricky area to know what to do. If my app did take off I would not hesitate to have professional translations done but the initial outlay price for, say, 20 translations could well wipe out any return. In 2 months I'll be older and wiser (if only in expletives from people who are insulted by the translations).
I'd love to hear any other responses from people who have had the same dilemma and to know their real life "app" experiences in this area.
A genuine thankyou to those who have so far written..
Paul
If your app is targeted at people who know english (geeks, system administrators, other computer people) then you better use english only UI.
Other way, if you target "common" audience you have to decide what do you want - bigger "client base" or higher app rating (because no annoyed people will rate your app 1 star because of bad l10n).
I'm russian myself and I can tell you that for me badly localized app is much more annoying than english app. But people who does not know english (there are a lot of them) will never install english-only app.
I have an application that was build with all the text in English. I would like to add more support for other languages, but am concerned about my users who don't necessarily care about the application now having support for Spanish or whatever new language I have added needing to update. Also, if I am correcting bad translations on a daily basis this would be really annoying to users.
One idea is to make calls to a web service that provides the content for there specific local, which would allow for easy changing if there are bad translations and what have you. The concern with this is of course the speed.
So is there a right way or a better way to add/change values in the localization without forcing people to update?
I understand your problem. And I have one question. Do you think that it will not be annoying for users if your application requests the external service every time when, for instance, new activity is opened?
To my point of view, you should add support of a language, test the correctness of your translation (for instance, you can ask a user from another country who use your application to check the translation) and only then update your app in the market. If all your string resources are in xml files it is not very difficult to support several languages.
So my proposal for you is at first extract all your string resources into strings.xml file (for default language folder), and then just make several values folders with additional language support.
Adding localization is usually (if you followed the good practices) a matter of upgrading a few XML files. So even if the users upgrade, it won't take long at all and they will probably not notice (if they use autoupdate) from the market.
Check this out for more details.