Given: library, which open own frames (fragments and activities), with own text fields and strings. Library has three files strings.xml for localization regions, where speak in English, Russian and Ukrainian.
Needs: give for user opportunity localize my library. I can't keep more languages, so it must do library's user.
Variant of solution: create Java-class with all text values (I has bit strings). User can set in this class values from his strings files and it take opportunity to localize by strings.xml file. But this varian so uncomfortable for user.
Question: how give for user opportunity to localize my library's strings?
I can solved this problem. I try to create in project (where uses library) folder with name values-de and put in folder strings.xml with strings names from library, but with another values. And it worked!
So: project-library can use values from project, if then defined with same names, which they defined in library-resources.
Related
I have just finished developing an android application that I was asked to make. I had also planned to translate it in different languages; below you can see the tree of the folders/files:
Inside strings.xml there are all the values that I am using inside the classes and they are all in Italian, my language (Here you can see an example if needed). I'd like to be able to translate all those fields in English and french as well.
I have read this article -> http://developer.android.com/training/basics/supporting-devices/languages.html
From what I have understood, I'd have to create a folder called values-fr with a strings.xml inside (it will have the same values names, but different translations).
QUESTION
I would like to be able to support English and Italian as well, but I don't understand how to manage the folders. Could you please tell me which option is the correct?
Inside the folder values use strings.xml with Italian (my language) strings. Then create another folder called values-en and, like I did before, create strings.xml with English values
Inside the folder values use strings.xml with English strings. Then create another folder called values-it and then, create strings.xml with Italian values
I guess that the point 2 is the correct solution but I'm not sure. The folder values has English as default language?
Thanks for the attention.
Technically speaking both are valid. values/ is the fallback if a more specific qualifier is not found. There is no written rule that enforces you in having the English strings in values/. It just makes a little more sense to have the English as fallback since it easier to find foreigners that speak English rather than Italian
I`m still learning android development and come with one app which I want to localize to multiple languages.
But please help me a little bit with values folder structure. I have main values folder and in it I have analytics.xml, strings.xml,styles.xml,mraid_attr.xml and colors.xml.
When I make new folder for localization, eg: values-fr I must put all of these files in it or just string.xml where I have translated strings?
You can just put your translated strings in your localization folder, but Lint will warn you about non-translated strings.
So if you have configuration strings (i.e no translation needed), create a separate XMl (like config.xml) and let only your translated strings on your localization folders.
I have an Android project that I developed one year ago. I didn't think in do the project multi-language and now I need support it.
There are any easy way to detect all strings and generate the XML file? Or I need modify the project string for string?
The project is developed in Eclipse.
Android provides a very simple way to localize apps: string resources.
You need to provide several strings.xml files.
Each in a directory called /res/values-xy, where xy is the language (i.e.: es, fr, en, de, it, ...).
Then just refer these strings in your project, like R.string.my_string_name (in Java) or #string/my_string_name (in xml)
For reference: http://developer.android.com/training/basics/supporting-devices/languages.html
[EDIT]
Same goes for arrays: just use /res/values-xy/arrays.xml
Note: the names strings.xml and arrays.xml are just conventional ones can be changed to anything you like better.
AFAIK You need to modify the strings in your project manually. If you have hard-coded strings in your layouts then you can use Lint to find out all the hard-coded strings. Put them then into values/strings and the translation should go to the respective folder of each language.
EDIT:
If you're running Eclipse you can use the search feature to help you track all your hard-coded String. Check this topic
In our multi-platform projects, we have multiple localization files with different notation and file format (iOS .string, Android .xml, etc.).
Now we want to localize them in many languages, but in the different files, there are many equal strings. so anybody knows of a good way to consolidate these strings-files to one big localization file, hand this to the translation agency and then splut them back up into the different files?
Anybody knows a good approach?
I've worked on an iOS/Android project with 20 translations, and we used an Excel spreadsheet to keep track of all the translatable strings. The *.strings files for XCode and the *.xml files for Eclipse are then automagically generated using my custom VBA macro.
I've put an example Excel spreadsheet with VBA macro here:
http://members.home.nl/bas.de.reuver/files/multilanguage.zip
You can convert your existing .strings or .xml files to spreadsheet format (key value pairs, tab separated) with the tool below. Then you can send the spreadsheet to your translators, they fill in a column of translated values, send it back and you can simply generate your new translation files.
http://members.home.nl/bas.de.reuver/files/stringsconvert.html
EDIT in 2021
The homepage is offline now, but I've added the Excel/spreadsheet example on github:
https://github.com/BdR76/Manage-translations
Was in the same situation with my app about a month ago.
If you use SmoothLocalize for your localization (which I would recommend as they are really easy and super cheap), you don't have to pay for repeat strings on the 2nd order. So you would pay the full 4c/word for your iOS localization, then just paste in your order number for the Android localization and you don't have to pay to translate them again.
Also if they are EXACTLY the same, they will convert a .strings to a .xml for you so you would only have to do one order, just email them.
Someone please explain what is the main idea of using strings.xml?
I think it would be useful for multi-language support but how can we organise it for that?
Do I need it if I don't want to use multi-language support in my android application?
The idea is that it represents a single location for various strings, so your code isn't peppered with string literals. In addition to that, you gain the ability to easily localize. Organization of files for localization is covered here:
http://developer.android.com/guide/topics/resources/localization.html#creating-alternatives
Do you need it if you're not localizing? No. But it may make things easier in the long run, and I would recommend using it just for that reason.
Hard-coding strings is Bad.
Parameterizing strings (e.g. with strings.xml) is Good.
Being able to internationalize your strings (with language and/or locale-specific versions of strings.xml) is even Better :)
PS:
To make use of internationalization, just create resource subdirectories. Google will give you plenty of references/examples. Herre's one:
http://developer.android.com/guide/topics/resources/localization.html
* res/values/strings.xml
Contains English text for all the strings that the application
uses, including text for a string named title.
* res/values-fr/strings.xml
Contain French text for all the strings, including title.
* res/values-ja/strings.xml
Contain Japanese text for all the strings...
And yes, you should absolutely get in the habit of using strings.xml (and colors.xml and dimens.xml etc etc) even if you don't plan on internationalizing immediately.
IMHO....