I have a current Android app that uses i18n via resources. res/values-es/strings.xml and so on. When I test it on a device with the language set to Espanol it pulls the correct resources, from the values-es file, but the accent characters are way out of whack.
For example, I want to use the lowercase o with an accent (ó). I have tried with the actual character in the strings.xml file (using the character map on Ubuntu to create the string) and with the entity, in either case it comes out like some other character set accent I don't recognize:
The same character looks perfect WITHIN strings.xml when using many different text editors. And the file is UTF-8 (tried recreating it with the Android "wizard" tool in Eclipse to make sure).
strings.xml
<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="label_app_version">Versión</string>
</resources>
Now I've used French, and German before in other Android apps, with all sorts of accents, and haven't seen this problem, so I'm entirely confused at the moment. What am I doing wrong this time?
I finally solved this one. I was using a font and calling setTypeface earlier in the code. The font I'm using must not have the special characters needed for the other languages. I need to check to make sure my user's are using a locale that my font supports before setting the font.
I should have realized this and checked it earlier.
So the bottom line is this, if you get strange results with certain characters in different locales, make sure you're not using fonts that don't support those characters. Fall back to not using a font (don't call setTypeface) and test that way.
That diacritic is actually called a breve, common in many eastern european languages. I had the same problems before once. I even have a question here on SO. Since nobody solved the problem, it's worth the shot...
This isn't clear to me yet:
Does it happen only on this project? Did you try others? (maybe a project mistake)
Try including other language folders (try, say, values-fr). Do you have the same problem?
Did you try to build your app inside Eclipse? Did you try building manually on the command line?
Then, you could try:
Instead of the "ó" (here in PT we use the same), try \u00f3. Like: Versi\u00f3n. Do you get the proper latin small o with acute? Just to clear things.
Build your app using ant ($ ant release) manually on the command line. Report back the results.
This may help the guys here (who are much more experienced than I am) guess where the problem can be.
Best regards!
Check how the actual strings.xml file is stored.
In the file tree in Eclipse, right-click on the strings.xml file and select properties.
You will get a properties dialog for the file.
If not selected already, select the "Resource" line in the left column.
Check the "Text file encoding" area at the bottom.
It maybe selected as "default" or a specific encoding such as "UTF-8" selected.
Select the UTF-8 option. Save file. Clean & Build project (to re-gen resources) and then see if any changes.
See attached screenshot.
Suerte, Andrew
This is strange as it should not cause a problem. Maybe you should try to embed string into CDATA section, like this:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="label_app_version"><![CDATA[Versión]]></string>
</resources>
Related
I'm designing an Android app that is to support 10 different languages/localities using Android Studio. The problem is that if I perfect the layout file for English it won't look right for other languages. For instance, some of the text might be truncated/cut off in another language because it is too long for the TextView, even if it is fine in English.
Is it possible to have language-based differences in font sizes in the layout (xml) file?
You should be able to create a layout-es folder to override the layout for the Spanish language etc. I have used it myself for drawables so I can't see why it wouldn't work for layouts too.
#darnmason's solution is correct -- locale-aware layout files do work, and to make it work, just duplicate the resource file in a layout folder with -xx, where xx is the language code. See the "639‑1" heading in this table for the language code.
So, for \res\layout\MainScreen.xml in French, the new file becomes \res\layout-fr\MainScreen.xml.
Despite Android Studio complaining that string resources should be localized into a (separate) resource file, it sometimes makes sense to use a duplicated locale-specific layout file; one such example is in the case referred to by the OP.
In general, try to do localization of text in a strings resource file. Sometimes, however, the translated text in one language would make the UI ugly in another language (compare length of "Nom d'utilisateur" with "用戶名", and the field sizes that result). In such cases, duplicate the layout file, as described above, as more than just the text (dimensions, perhaps fonts) is being localized.
The downside of using an additional layout file per language is that each time something changes (e.g. adding a button), multiple layout files need to be updated with all changes, rather than just adding the control to one layout file, and adding all translations to a separate strings resources file.
I am working on a simple android application in eclipse IDE and I got a little yellow icon on the left hand side of a line of xml code that looks like a light bulb with an exclamation mark beside it. When I hovered over, it says "[I18N] Hardcoded string "input..., should use #string resource input". The running and debug was successful but I just want to get rid of it as I find it annoying. What should I do?
If it's annoying, there is a reason. You totally should use #string resources instead of your hardcoded strings. All you have to do is to put your string in res/values/strings.xml and reference it in your layout via #string/my_string_id_here.
This is extremely useful for multi language support, or for plurals strings.
You can learn more here.
Hope this will help you.
The right way:
Move all your strings into resource files, as suggested, and reference them in your views like so: #string/mystringname
The "other" way:
Turn off Lint warnings in Eclipse in Window/Preferences/Android/Lint Error Checking
Both ways will remove that annoying triangle :)
This warning is there because hardcoding strings into the android app's Java source code is not recommended. It will compile fine - but Android Lint will complain about it, so that's why it's a "warning" and not an "error". Generally, it is preferable to define them in the separate "string.xml" file.
If you want to know why, check this answer.
For an example, check this answer.
You should also take a look at the official documentation for string resources.
I've defined a template to use to help typing out XML string definitions, which I've given the name "astring". In Content Assist, I've turned off XML Tag Proposals:
But I still get these two extraneous options "string" and "comment" coming up as the top suggestions when I hit Ctrl+Space
Am I doing something wrong? Why does unchecking "XML Tag Proposals" and changing the order have no effect?
update:
1) It seems like the extra XML tag proposals only appear in the Android XML editor, not the "standard" one
2) However I get extra template proposals coming up in both editors, until I type some extra characters to narrow down the name.
I am not sure if this is a bug or by design. I think a bug, because I would expect it work like the Java completion whereby it takes into account the characters already typed, as soon as I press the completion key.
So a workaround for the normal XML editor is to press Ctrl+Space before starting to type the name of your template. But you still get the Tag Proposals in the Android XML editor.
Should I enter this as a bug in Eclipse or in the Android plug-in, or both?
Are there any default XML templates (XML / XML Files / Templates) that might be similar to the tag proposals?
You can also check Windows > Preferences > General > Editors > File Associations and switch to a different XML editor of your liking.
As a last resort, try changing the locale to English/US temporarily to avoid a known bug and restart Eclipse. Visit Control Panel; Region/Language, Administrative (or Advanced); Language for non-Unicode Programs; Change system locale.
Maybe this is a silly question but is there a difference,besides the obvious,between
android:text="#string/...." and android:text="..."?.I'm thinking that maybe the text that appears on the screen has the option for styling when using #string.Which one is best to use in general or it really doesn't matter?
When you're using android:text="#string/" the app is going to find the value of the string in the ressources file, with this technique you can manage multilanguage app, with a "strings"'s file by language.
Choice Matters, if your app has a lot of text in it, supporting a different language would be easier if you used #string, you would not have to scramble through every xml file to add text in the other language for every piece of text, simply go to strings resource and change there.
But then again, when checking UI for errors after work is done, it might make life harder (or work boring) as fixing a typo would require you to go to the xml file that the erroneous text is located, look up the name of string and then go to Strings to correct (unless you were very organised and named things well in your Strings such that you know which text belongs where)
Where can I find the source code of the definition of the android default styles, such as ?android:attr/progressBarStyle?
I know that the Android repo is replicated in https://github.com/android but... I just can't find the styles.xml, strings.xml, etc there!
In the value resources directory.
With the ADT plugin in Eclipse, you can just type android.R.somegroup.someconstant, then mouse-over and hold CTRL (doesn't even have to be syntactically correct/compilable for that) -- this will give you a popup with two (or in case of strings.xml more) options to "Open declaration in [some XML file]".
For reasons that escape me, this doesn't seem to work for any of android.R.style.* -- for everything else it does (color, string, layout, ...).