Hello there fellow Android developers. I am looking for some feedback. I am about to do a major international deployment of an android application. Something I need to worry about is language settings. What I have done right now is used the default language setting specific /res/values- setting where you have multiple folders called values-en, values-es, values-pt, things like that. So what I am wondering the following.
When my android default strings.xml is in English, will the way I am handling language be sufficient. It works here in development and probably deployed from the US store. But when deployed from other stores will the device think, I am from the Spanish store so the default strings.xml file should be in Spanish, or will it know, I am Spanish store so I will use values-es?
Anyways I would like feedback from someone who has deployed like this before please. It seems to be a question that is pretty guessable, however I am wanting to confirm with other developers what their experiences have been.
Thanks,
Anthony
If your read this page, it stated :
To add support for more languages, create additional values
directories inside res/ that include a hyphen and the ISO country code
at the end of the directory name. For example, values-es/ is the
directory containing simple resourcess for the Locales with the
language code "es". Android loads the appropriate resources according
to the locale settings of the device at run time.
Add the string values for each locale into the appropriate file.
At runtime, the Android system uses the appropriate set of string
resources based on the locale currently set for the user's device.
The language folder that is used is based on the user's selected language, not anything relating to where they are. You can test what each language looks like in your app by changing your device to a different language.
From my experience, the selected language resource is based on the selected language on device, so no matter which store your app is downloaded from, if the device language setting is english, values-en will be selected.
But you don't need to worry about it, as long as you have i18n files for all language you want your application to be translated to, the device will do the rest of the work for you.
Related
I am developing a point of sale desktop app in English for forms.
I want to add Arabic language: the user can switch from one language to another.
What is the easiest way to do this?
Java supports internationalization out of the box, please see Internationalization tutorial. Roughly, you should
Move all UI-related messages to separate *.properties files
Create separate *.properties file for every supported language
Resolve required messages file by Locale (language)
No tutorial presents a concrete example of how an internationalization plug-in fragment is created an used. I need translations to the plugin.xml's and source code files. Trying to wrap my head around where the translations go, and where the i18n facade goes.
1. How does that fragment apply to an multi-plugin enterprise application, and more importantly, how do all those plugins externalize their strings inside appropriate folders in the fragment?
2. What about external JARs? How does the mechanism provide translation support for external resources?
3. With the risk of being a long-shot, would it be possible to provide independent translation of a view or perspective? Not necessarily at runtime, because I know bundles can't be dynamically switched.
There is some help available, this article lists the process. It's based on Eclipse 2.0 (!) but the basic ideas are still correct.
An even better article is this tutorial by Vogella
For each plugin you need to translate, you will create one plugin fragment. The fragment is associated to one host plugin, so you need several fragments. Each fragment can contain several languages though. The languages are separated by the folder structure as described in Step 5 in the first article
I am guessing you are referring to non-eclipse Java jars that you have made yourself, yes? If so, that is a completly different process, best suited for a separate question with the Java tag. Oracle has a guide that may help. But keep in mind that you only need to translate the content that the user is exposed to. So a refactor to keep all user visible strings to the Eclipse plugins might be a good idea.
Are you referring to the name of the view/perspective? If so, yes. You can translate the information you give in your plugin.xml aswell. See Vogellas article, chapter 3
Edit:
At nr.3 I was referring to choosing which View to translate (e.g. via a view menu), then restart the app, then only the said view should translate
Well.. I think of a way that would work in theory, but I'm not sure its the best alternative.
So translatation is based on locale. And given the locale a certain translation is chosen. If no appropriate translation exists, a default will be selected.
So if your View menu were to change the locale of the application to, say "us-en-v1", and you only had one view which had a translation for the locale "us-en-v1", that would mean that particular view would be translated, but the rest of the application would use a default (could be that they default back to the closest translation, dont remember exactly).
Then for each view you would create a new translation and use a unique locale for each.
That should work, but it abuses the way translations are supposed to work, so it could lead to issues.
I've done something similar at one time, one app was used in the same language but different customers had different vocabulary. So we used the i18n to make the application use the right terms by defining our own locales.
We are using http://babel.eclipse.org/babel/ to let people translate existing ressources. The build process adds the required language fragments to the artefact. Each plug-in defines its own Messages.properties / Messages.java file.
I guess, you can't do much about external jars.
For instance:
public final class MyMessages {
// a string member as you reference it later in the code
public static String login_window_user_label;
// static initializer which initalizes the fields in this class
static {
NLS.initializeMessages("mymessages", MyMessages.class);
}
}
And (usually in the same package) you have a properties file, in this case,
mymessages.properties
which includes the string:
login_window_user_label = Enter username to login to {0}
And within the code you do:
String userNameLabel = NLS.bind(MyMessages.login_window_user_label, Environment.getName());
Thats how we make our bundles "translatable". The build generates the language fragments and the babel server instance allows the translation.
I have a web page which has 3 different languages, Swedish, English and Russian! In my old java page i set this up with WebTexts_en.properties, WebTexts_sv.properties and WebTexts_ry.properties files together with LangSupport.jsp to chose the Locale for the browser.
All my jsp pages has UTF-8 encoding so this should be correct as well i think.
Now i have moved my page to Google APP Engine and i wonder if there is anybody who have some input on how to make this here? I have tried to follow my old setup but it seems not to work, my page are there but i have no text what so ever, http://neptune-app-id.appspot.com/
So i wonder if there is anybody who have some input on how google like to set this up? I need help with the whole setup of this, where to place my files, what to include to get this to work, How to setup up my LangSupport file so it choose the right Locale for the browser.
Would also be nice if somebody could show me some documentation for this that i can follow when i set this up. I am quiet a beginner with this but i have most of the files from my old page. Sp i only need to convert all this to work with google app engine instead, please help!!!
Any information would be very helpful since i am stuck right now and cannot move forward with my project.
You have locale and dependent on locale you should take properties from correct property file. You can define you EL function that will have messageId and locale parameters. Depending on locale you can load properties from file you need and depending on messageId you can get message you need.
Put ptoperties files to WEB-INF/ so you can load them with java core Properties.
Thats all.
I am developing one Android application in three languages named English,Spanish and German.First I completed development in English and wish to complete it in other two languages. Here my question is:
Can I use the same code of Android project(which is in english) in the other two languages with different package names in the same project ?.
Please help me with the sample code/links.
of course you can. Follow these steps
make sure all of your strings through the application are listed as a resource in yourAppFolder/res/values/strings.xml and that you use strings in your app only via getString(R.string.myString1) and NEVER via hard-coded strings in your activities
create a new folder for each language you want to localize your app with the following syntax: for germany, values-de
copy the strings.xml file in the new folder you just created
translate each string in the file into your desired language
Now android OS will use the proper language based on the device's locale.
I bet that you don't fulfill requirement #1 and that will be the most of your work to do. At least that was happened to me in my first real android app ;)
I have an application that pulls information from a web server and displays it. I know that Android has some nice language features where you can put multiple strings.xml files inside the project for specific languages. Is there a way to convert the text from the server (which is in english) to whatever local the user has set on their device?
Thanks
Yes, but that's usually done at the server-side with some kind of translation api. Even on Android, when an app needs content that hasn't already been pre-translated, it goes through a server for the translation.
For instance, you could use Google Translate's api (which is not free)
http://code.google.com/apis/language/translate/overview.html
Or you could install some open source solution on your own server and use that remotely as well.