Why do some Android projects list a "CHAR_LIMIT" in comments above each string in strings.xml? For example, from https://android.googlesource.com/platform/frameworks/base/+/master/core/res/res/values/strings.xml:
<!-- [CHAR LIMIT=25] String for confirmation button to enable a feature gated by the battery saver warning-->
<string name="confirm_battery_saver">OK</string>
<!-- [CHAR_LIMIT=NONE] Battery saver: Feature description, with a "learn more" link. -->
<string name="battery_saver_description_with_learn_more">To extend battery life, Battery Saver:\n·Turns on Dark theme\n·Turns off or restricts background activity, some visual effects, and other features like \u201cHey Google\u201d\n\n<annotation id="url">Learn more</annotation></string>
Googling turns up a few other examples, but no explanation. I don't believe Android documentation covers this. And unlike tags like <xliff:g> it doesn't seem to be an official, functional component of Android. My best guess is that it's a convention some projects use to indicate "when you translate this, make sure the translated version doesn't have more than X characters or else it will break the UI!" Or perhaps, vice versa, "if you're using this String, make sure the UI still looks good with a String X characters long"
My thought is that the UI should always be built to be as flexible as is reasonable, given the possibility for translations of different lengths, and the possibility of different text sizes. Also that translators should strive for the translation to be more or less the same size as the original text, instead of going from, say, 10 characters to 50 characters when translating. So I would think this "CHAR_LIMIT" would be completely unnecessary and could be dropped. (I ask, because I'm touching up an old open source project that uses this.)
Is my understanding of "CHAR_LIMIT" correct, or what is it for, and should it be used?
when you translate this, make sure the translated version doesn't have more than X characters or else it will break the UI!" Or perhaps, vice versa, "if you're using this String, make sure the UI still looks good with a String X characters long
That's pretty much my understanding of it.
I searched around a bit for where this clue is used, and I found only a single place: stringslint.py. This is a lint script that seems to be used on strings.xml files. Maybe the project you're talking about used this script? The file docs say:
Enforces common Android string best-practices. It ignores lint
messages from a previous strings file, if provided.
Usage: stringslint.py strings.xml
Usage: stringslint.py strings.xml old_strings.xml
In general:
Errors signal issues that must be fixed before submitting, and are only used when there are no false-positives.
Warnings signal issues that might need to be fixed, but need manual inspection due to risk of false-positives.
Info signal issues that should be fixed to match best-practices, such as providing comments to aid translation.
So that goes along what you were saying. It's a clue for translators but can also be used for lint checks, hence the easily parseable syntax.
I also tried to search for pages explaining how one would translate the Android System, hoping CHAR LIMIT would be mentioned somewhere. But it doesn't seem like the community can contribute their own translation, so I found no such page.
Note that there's also a BACKUP_MESSAGE_ID that's declared in the same way for some string resources. It seems related to the system Settings app, but I don't know any more that than.
EDIT: I found another script using it: https://chromium.googlesource.com/chromium/src/+/master/tools/grit/grit/tool/android2grd.py, although this time it's CHAR-LIMIT.
Related
I have a full-fledged working Flutter app. Now, I want it to support multiple languages, such as Spanish, Hindi, Urdu, etc. (primarily Indian Languages which are available in Google Translate).
I have searched about this, but all of them mention about "arb files" in which I believe, I have to manually write each and every translated string of the whole app.
I would like to build a package with a class (or just a method) which may require 2 parameters, string and the locale in which translation is required.
Kindly suggest me the best way to achieve it and how can I do it. A link to tutorial would be appreciated.
Flutters own step by step walkthrough to i18n is literally the first result that pops up when you put "Flutter localization" into Google.
https://docs.flutter.dev/development/accessibility-and-localization/internationalization
If for some reason you don't want .arb files, you can roll your own. But be prepared that you will find out along the way what is missing and ending up with a home-brewn solution that is worse than Flutters own to achieve the same thing.
There is no magic function to translate text. Even if you could translate on the fly with a translation service, translation services have become really good in recent years, but they (as any human you could hire) are only as good as the context they get. If they get only single words or half sentences, as is common in an app with headlines and buttons, the result will be horrible. As if you just put every single word into a dictionary. That is not translation. It will feel artificial and laughable.
So... give the existing packages a try. Start with Flutters. It might seem complicated, but it's complicated for a reason.
Background
TextView always had issues with RTL (Right-To-Left) languages. Since I know only how to read Hebrew (in addition to English), I will talk about its issues:
Text alignment (and I'm not talking about gravity) . As an RTL language, Hebrew puts words from right to left (compared to English which is the opposite).
For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".Hello world" . This could be easily fixed if you had it in a single sentence, but it's harder when there are multiple punctuations characters.
Vowels positions. Hebrew doesn't require vowels in order to read text, but sometimes it's very hard to read without them (especially the bible). For vowels, Hebrew has what is called "NIKUD", which are actually like dots inside the letters. The problem in Android was that they were usually positioned in the wrong location .
For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".eHlol owrld" . Even if you try to fix it (put the vowels always one character after the current one), the position in the letter wasn't correct (imagine that the "e" in "Hello" would be like above the "H", for example) .
Only on version 4.2 (read here, under "Native RTL support") , Google has fixed all of the Hebrew related issues (or at least it seems so).
The problem
the problems with Hebrew has caused each Israeli carrier and each custom ROM maker have its own solution of how to fix the different issues, which makes it practically impossible to handle RTL text on pre 4.2 devices.
Things can get even more frustrating in case the text include both Hebrew and English letters.
What I've tried
I've read many websites talking about those problems, and I've tried many variants of the solutions, none has solved the problem on all devices:
Some suggest to put the character '\u200F' (or '\u202D') at the end/start/both of the text.
Some suggest using Html.fromHtml() method and put something special there.
Some even suggest to use the WebView instead (and maybe use WebSettings.setDefaultTextEncodingName() ).
The question
Is there a definite solution for this problem?
I would assume the best thing is that because Android 4.2 solves this, and Android is open source, we should have its TextView imported into a library that we can use, but Google hasn't provided such a library yet.
Sadly, I don't think there's a good solution ("good" meaning "does the job and is readily available"). For our own Android apps that support Hebrew, we use a custom rendering mechanism that we developed over many years. The rendering mechanism does everything: proprietary fonts; bidirectional (bidi) analysis; glyph placement; line break analysis; text flow; etc. Some of the problems trying to use native Android text handling capabilities (especially pre-4.2) are:
Really crappy fonts. However, you can package third-party fonts like DejaVu that are pretty good. The right font can do wonders with positioning of nekudot—and te'amim1, if you need that. (I agree with you about how important correct pointing placement is; reading Hebrew text with misplaced nekudot is like reading a screen-full of CAPTCHAs.)
Buggy bidi analysis. What makes it worse is that the bugs seem to be different for different versions of Android. Modifying the text to include strategically placed bidi formatting codes (RTL mark; LTR mark; etc.) can overcome many of these bugs (see the discussion here, which isn't specific to Android). However, it's a nuisance to do this and, because of the inconsistencies among Android versions, it is difficult to predict in advance what help the framework is going to need.
No (or poorly thought out) framework-level awareness of right-to-left issues. For instance, good luck getting the scroll bar to display on the left side of a Hebrew TextView. For our apps, we had to build an entire scroll-bar system just to get this to work how we wanted. (Good think Android is open source!)
Poor line and word break analysis. At least one early version of Android on which we tested thought that each nikud mark was a word boundary. When it comes to line breaks, the system often doesn't know how to handle Hebrew punctuation like maqaf, gershayim, or sof pasuk.
Some of the newer Unicode characters (like HOLAM HASER FOR VAV—U+05BA—new to Unicode 5.0) are not recognized as Hebrew script by the system.
My recommendation is that, unless you are prepared to build a top-to-bottom text handling system yourself, you give up on high-quality text display on pre-4.2 versions of Android, particularly if you need to support nekudot and te'amim. Also, plan to use the techniques I mentioned in the first two points above.
1 biblical cantillation marks
As of August 2013, Android has posted API documentation for a Bi Directional Formatter which might suit your needs. This is contained in the Android Support v4 library which I believe should run in versions prior to Android 4.2.
Refer to:
http://developer.android.com/reference/android/support/v4/text/BidiFormatter.html
I have a lot of dynamically generated TextViews (being fed to a list array adapter), and each of their text contains a summary of a lot of small information. In an effort to improve UI, I used some styling when displaying information, like so:
(4 Votes) ☬ [tag1] [java] [regex] ☬ 2 min ago ☬ author ☬ 245 points
This line is constructed using a StringBuilder. This line (let's say) looks nice, but not friendly to accessibility tools such as "Google Talk Back". It reads like so: "four votes unknown character bracket tag one close bracket..."
So to fix that, I'm generating another string and set it for content description, like so:
Asked by "author", who has "245" reputation points, received "4 votes" since "two minutes ago", these are the tags: "tag1", "java", "regex".
This line would also be generated using StringBuilder, essentially doubles my run-time.
I'm asking:
Is this really doubling my run-time? Is it worth it? Obviously only a very small percentage of people would need accessibility tools, but looks like I'm sacrificing everyone else's CPU cycles.
If it indeed has a negative impact on performance, how can I improve it? Is there a way to detect whether "Talk Back" is used? Is android smart enough to detect this itself, and ignore setContentDescription() line?
I don't think its worth worrying about unless your app has performance issues. But it you do, you can always turn it on or off based on if any accessibility settings are turned on. You can check for enables accessibility apps in Secure Settings.
Background
TextView always had issues with RTL (Right-To-Left) languages. Since I know only how to read Hebrew (in addition to English), I will talk about its issues:
Text alignment (and I'm not talking about gravity) . As an RTL language, Hebrew puts words from right to left (compared to English which is the opposite).
For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".Hello world" . This could be easily fixed if you had it in a single sentence, but it's harder when there are multiple punctuations characters.
Vowels positions. Hebrew doesn't require vowels in order to read text, but sometimes it's very hard to read without them (especially the bible). For vowels, Hebrew has what is called "NIKUD", which are actually like dots inside the letters. The problem in Android was that they were usually positioned in the wrong location .
For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".eHlol owrld" . Even if you try to fix it (put the vowels always one character after the current one), the position in the letter wasn't correct (imagine that the "e" in "Hello" would be like above the "H", for example) .
Only on version 4.2 (read here, under "Native RTL support") , Google has fixed all of the Hebrew related issues (or at least it seems so).
The problem
the problems with Hebrew has caused each Israeli carrier and each custom ROM maker have its own solution of how to fix the different issues, which makes it practically impossible to handle RTL text on pre 4.2 devices.
Things can get even more frustrating in case the text include both Hebrew and English letters.
What I've tried
I've read many websites talking about those problems, and I've tried many variants of the solutions, none has solved the problem on all devices:
Some suggest to put the character '\u200F' (or '\u202D') at the end/start/both of the text.
Some suggest using Html.fromHtml() method and put something special there.
Some even suggest to use the WebView instead (and maybe use WebSettings.setDefaultTextEncodingName() ).
The question
Is there a definite solution for this problem?
I would assume the best thing is that because Android 4.2 solves this, and Android is open source, we should have its TextView imported into a library that we can use, but Google hasn't provided such a library yet.
Sadly, I don't think there's a good solution ("good" meaning "does the job and is readily available"). For our own Android apps that support Hebrew, we use a custom rendering mechanism that we developed over many years. The rendering mechanism does everything: proprietary fonts; bidirectional (bidi) analysis; glyph placement; line break analysis; text flow; etc. Some of the problems trying to use native Android text handling capabilities (especially pre-4.2) are:
Really crappy fonts. However, you can package third-party fonts like DejaVu that are pretty good. The right font can do wonders with positioning of nekudot—and te'amim1, if you need that. (I agree with you about how important correct pointing placement is; reading Hebrew text with misplaced nekudot is like reading a screen-full of CAPTCHAs.)
Buggy bidi analysis. What makes it worse is that the bugs seem to be different for different versions of Android. Modifying the text to include strategically placed bidi formatting codes (RTL mark; LTR mark; etc.) can overcome many of these bugs (see the discussion here, which isn't specific to Android). However, it's a nuisance to do this and, because of the inconsistencies among Android versions, it is difficult to predict in advance what help the framework is going to need.
No (or poorly thought out) framework-level awareness of right-to-left issues. For instance, good luck getting the scroll bar to display on the left side of a Hebrew TextView. For our apps, we had to build an entire scroll-bar system just to get this to work how we wanted. (Good think Android is open source!)
Poor line and word break analysis. At least one early version of Android on which we tested thought that each nikud mark was a word boundary. When it comes to line breaks, the system often doesn't know how to handle Hebrew punctuation like maqaf, gershayim, or sof pasuk.
Some of the newer Unicode characters (like HOLAM HASER FOR VAV—U+05BA—new to Unicode 5.0) are not recognized as Hebrew script by the system.
My recommendation is that, unless you are prepared to build a top-to-bottom text handling system yourself, you give up on high-quality text display on pre-4.2 versions of Android, particularly if you need to support nekudot and te'amim. Also, plan to use the techniques I mentioned in the first two points above.
1 biblical cantillation marks
As of August 2013, Android has posted API documentation for a Bi Directional Formatter which might suit your needs. This is contained in the Android Support v4 library which I believe should run in versions prior to Android 4.2.
Refer to:
http://developer.android.com/reference/android/support/v4/text/BidiFormatter.html
If I wanted to translate an entire app (with button names and labels, and long text), is it better to just make a different app? Or is there a translation api I can use?
The reason I ask is that I tried going to the Goolge Play store and searching it in a different language, and it basically didn't understand what I wanted. So is there a different Goolge Play interface for different languages? Or some setting which I need to turn on?
How does this generally work?
Thank you!
use all your strings from a file instead of hard coded way. the name of the file is strings.xml in values folder, and for another language what u need to do is to crate values-ru values-ch etc. folder and put your strings.xml inside the folder. and change the values. this was a fast approach to explain your solution. for expanded, detailed solution is here : http://developer.android.com/guide/topics/resources/localization.html
You don't want to make multiple versions of the application. In general this is accomplished by using a locale-specific dictionary for each translation you want to use, so instead of hard-coding strings in your application you would reference an element in the appropriate reference database instead, which is basically a list of all the strings you use in your application.
Here's some information I found specifically for Android development: http://developer.android.com/guide/topics/resources/localization.html
As for translating, natural language processing isn't far enough along yet to give good translations automatically, especially without context. You can try Google's translate API (https://developers.google.com/translate/) which uses some statistical methods, but even that will likely give you erroneous translations (I'm sure you've probably used Google or another service to translate something and out came something you could be pretty certain wasn't accurate). You might be able to use that as a first step to converting the application to different languages and, if your application is open source (or even if it isn't) ask for user input as to the accuracy of the various translations.
Hopefully that is helpful.