In relation to a school project we're working on a mobile application for Android, we can't find out where it would be natural to keep our language modules.
We're thinking of either keeping the ressource files for every language locally on the cellphone hence keeping them close and available - or in our online database for saving space on the cellphone, but therefore requiring clients will need internet access to switch the language.
Thanks in advance!
For static content you should prefer to deliver them within your apk. How you already mentioned this make switching language more easy and this is the most natural way. Here some documentation about multi language support https://developer.android.com/training/basics/supporting-devices/languages.html
Saving space could be necessary but how many space takes each of your translations? Often it's better to use proguard to shrink your apk size.
For dynamic content like blog posts I would prefer an online database. Then you don't need new releases for updates.
Related
I've read a fair bit about localization on Android, but I've yet to find a single guide on how to implement localization at scale. The Android platform provides fairly extensive coverage for static apps - however, what if my app uses multiple online services that do not have multi-language support but do have (a very large set) of constant values that could reasonably be translated? Should this be done?
For example, I have an app that shows flight data and uses a service that only has support for two languages. If I wanted, I could add all flight statuses (Delayed/On-Time/Final/Boarding/etc), all cities and all countries to a few tables on an internal app database.
I have not calculated how much storage space this will take, but my guess is - this will require quite a bit of storage. Is the tradeoff worth it? I could also maybe launch my own service and query it, but I feel this may be a very expensive solution that only enterprises can afford.
Most of localisation services just store strings and help Android/iOS teams to sync it. I don't think what it's necessary to implement your own service. For example you can use POEditor or Lokalize.
Preparing:
You get all keys from Android/iOS app and load it with values in string localisation service.
About localisation on scale:
When team work at some feature programmers load new strings in service (keys and for example English version) and send request for translation (for example Chinese, German, Spanish etc).
When translators answers what translation ready and loaded to localisation service you sync this strings, see differences in git and check for potential bugs.
Hope it'll help
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.
How the app works
Currently an app is in the works which utility is to explore activities in 5 regions. Each activity is represented as an JS object with a fair amount of properties. Activities can be viewed through different filters in their respective tab, for example categories or a map. Inside each main filter, there are options to filter on date, region, accessibility etc.
The challenge
There is a lot of JSON that needs to be stored on the device, and support is required for both iOS and android.
In the best case scenario the data needs to be in sync with the database, and all data needs to be available on the device. The app will need to be snappy for a good experience, this means that fetching data needs to be as fast as possible. Furthermore, filtering data needs to be as snappy as possible.
Viable solutions considered so far (which don't quite cut it yet)
MongloDB with the MongloDB Titanium Store adapter, silver bullet?
This approach at first seemed be the silver bullet. Although the project seems promising, it is maintained by one heroic hacker, and the project is in need of some documentation. I have inspected the source, and hacked my way through the API, but to no avail, console.log and jasmine tests won't cut it this time. More important still, it is not quite finished yet, and features compared to MongoDB are missing. A great project, I hope it will catch on more and be capable enough to assist desperate titanium developers in the future.
JSONDB, only for iOS
This app really needs to work on both platforms, iOS and android, so no reason for trying this. Moreover, JSONDB works within a single context only, which would be a serious concern as well.
Ti Filesystem and JSON.stringify + JSON.parse, not memory efficient
A viable solution for saving a small list of saved items, which is also a feature in the app. But in other posts issues over memory limits with the use of JSON methods have been noticed for android. Though this might not be the least of my problem, memory efficiency overal will be a huge problem. Never have I seen benchmarks for performance with file reading and writing for Titanium, so I am not sure how big of an impact reading and writing would be. Filtering big objects is a huge concern as well, underscore won't manage this kind of big data. Iterating big objects is a huge problem no matter what approach I will choose.
Big ass global object
Practically the same approach as a Filesystem, only keep it in a global. This has the same issues and is just a plain unethical practice.
SQLite, yuck
Highly document oriented JSON data to SQlite, it sounds worse than samsung galaxy fanboys. Any feedback on this?
Multiple files + SQLite to maintain + lazy load, unicorns and rainbows?
Desperate for a solution, I might be onto something in the course of writing this post. There are probably something 10-16 main categories which each 1 to 4 subcategories. Keep all the activities for a subcategory in it's own file, which is a quite slim JSON. Browsing through categories, each subcategory is rendered in it's own TableViewSection, each subcategory be appended independently to the table based on how much the user is scrolled down, effectively lazy loading the content. There is only one quite quick file read. Within this view adding more subfilters effects only the already loaded items, and iterating this items is reasonably affordable.
Updating the data is also quite effective, only files that are subject to change are updated. A SQLite database can maintain the dates of all activities which have a expiry date, it can dynamically build it's own JSON file for the upcoming seven days or month. This will make the calendar view quite smooth for most usage. Picking future dates will be a nightmare though.
Still the map is an issue...
If you have read all of this, thank you. If you have experience with something similar, or might be onto something, feel free to reply! I have to quit writing, quit coding and start sleeping.
Sorry for the crappy monglodb docs. I developed it for some internal projects and really wanted to share it with the community, but the lack of docs does make it hard to use. But great news I have docs now lol also slimmed down and cleaned up the source code. Hope it works better for you now. http://monglodb.com
I'm the original author of JSONDB and thought I'd drop in and provide an answer for anyone finding this question via Googlefu.
JSONDB is now deprecated software - it's been replaced by another project called SculeJS. SculeJS aims to provide a full featured NoSQL database written in pure JavaScript for use in Titanium, NodeJS, and web apps.
JSONDB was originally only available for use in iOS applications due to limitations in the way Ti native modules were built - the current versions of JSONDB and SculeJS are compatible with both iOS and Android apps.
In a lot of ways MongloDB and SculeJS are similar, where they diverge is in the way SculeJS has been engineered. SculeJS is intended more to provide powerful, generic data structures with a rich query layer rather than being a straight port of MongoDB. No insult to Monglo - it looks like great software, I just wanted to point out the difference in intent between the two projects.
As a side note - all pure JavaScript modules are limited to to a single execution context within Titanium applications.
For what you're building I think MongloDB, JSONDB, SculeJS and TaffyDB would all do the job, the details of the implementation would just be slightly different.
I was encountering the same problem. I had about 5mb's of data which I wanted to store with the app, and not let it download.
I finally ended up with an SQLite database, with high performance. It is not as bad as you think. It might not be a nice solution ,but for the lack of choice it is a very good one IMHO.
Just create a couple of tables, and functions to parse them to database, and the other way around, and I promise you, you will be happy.
DO NOT store the JSON in the database, but store the values appropriately.
I have android application that is written "regular" way. layouts, java, APK.
Now, depending on some factors I want data to be presented differently to different users with different preferences, etc. Doing it using XML layouts will be very problematic in couple of reasons:
Upgrade issue - we have bunch of users and they not good at upgrading.
Hard to maintain and code.
So, I'm toying with idea of "templates" where we can serve templates from server and just use device to generate those.
Web app won't work because our data available offline in case there is no connection.
There is buttons and stuff that user can press to call regular Activities and do things.
I envision something like:
HTML 5 template with {tags} that I will populate from data. I will receive tempaltes and data separately from server. I will merge that data and display on UI.
Now my question is how do I:
Display HTML5 inside Activity
Intercept button push in HTML in my Java code?
Is this bad idea to write something like this?
It sounds reasonable to me. You can use a WebView for displaying the content. Your app can manage a cache of downloaded templates and other content and display it in the web view either from the web site or from the cache if offline.
I think your objections to layouts are offbase. You really might be better off with layouts. Here's why:
Your app can be set to auto-update by users if you do not change permissions. But pushing updates to your app will remain an issue unless your app is entirely web-based. (not a bad approach by the way) But so long as you have a native app, you will need to push updates from time to time.
And as far as being hard to maintain and code, layouts are specifically designed to make this type of customization manageable. You can break pieces of the layout common to different settings into separate files, and add them with includes.
You can use fragments to adapt to a variety of form factors.
You can serve up different layout based on screen size, language, orientation, or any of a wide variety of variables.
Check out some of the series on layout tricks, and get more familiar with being a layout power user. I think in the long run it will save you a lot of effort, assuming you don't switch to making your app a web app instead.
http://android-developers.blogspot.com/2009/02/android-layout-tricks-2-reusing-layouts.html
http://developer.android.com/resources/articles/layout-tricks-merge.html
http://android-developers.blogspot.com/2009/02/android-layout-tricks-1.html
http://www.curious-creature.org/2009/03/16/android-layout-tricks-4-optimize-part-2/
Google: Android Layout Tricks.
Great stuff.
Another benefit: Compiler checking. No broken functionality because a variable or field has the wrong name. Not the case with HTML.
Another benefit: works offline too with no messing around.
And last - you will have a non-trivial amount of work attempting to get this hybrid HTML stuff working the way you want, and then have a very unusual and custom code base that nobody here on Stack Overflow will be able to help you with. Stick with Layouts and there are lots of experts who can help you tackle the stickiest layout puzzles.
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.