I have a project that depends on another library I made. Both have crowdsourced translations, which I update periodically. In most cases, I will only add translations per project when they are complete. However, it may be that one project has translations that another language does not. In this case, I'd like to strip that translation in the production app. Is there any way of doing that?
Related
I am working on an application where it is required that I have to change.update string resources declared in my String.xml file over the air without uploading a new version on stores. (From server)
Currently, it is already implemented by Localazy and Phrase Android SDK.
The client wants to update anything declared in the String.xml and for every local.
I have to do it for multiple languages. I have already implemented localization. But the app still requires dynamic changes in the String resources,
As the author of this technology at Localazy, I can explain it pretty well.
How do we change strings.xml on the fly? We don't.
Our Gradle plugin adds a library to your app, performs bytecode analysis, and routes all the relevant method calls through our library. The library itself acts as a proxy, updates its internal strings database from our servers, and serves updated strings whenever possible. It also calculates anonymous stats about string usage, etc., to optimize the translation process on the Localazy site.
All of this happens during the build time without ever touching your source code and resources. It's completely transparent.
While it sounds like a simple task, it's much more complicated as it's impossible to route all method calls easily. E.g., LayoutInflater uses a different method for obtaining strings, and the same applies to Preferences, Menus, etc.
We also download and merge your strings.xml with the latest translations available on Localazy as the standard system method is always a reasonable fallback. We must correctly handle edge cases such as language aliases (iw vs. he), RTL languages, etc.
One of the biggest challenges was correctly supporting build types, product flavors, libraries, and dynamic app modules. It's not just about serving strings from the internal database but selecting the right one. E.g., a string with the same key from a library has lower priority than the app's one. The situation is different for dynamic app modules.
We've designed Localazy to handle all of these situations from the ground - the library, how we store strings on our servers, etc.
It's not a simple task to do this correctly, so better use the existing solution if possible.
Feel free to ask me if you need further help.
It is a tedious task to localize app's for multiple languages, and very often the same work is done over and over again:
For example, phrases like "OK", "Cancel" are in almost every android app.
Localization of mobile apps - Any resources available for the basics?
This question is 3 years old, I wonder if anything changed since then.
Are there any comprehensive libraries/collections which take care of this? So that I only have to translate the actually app-specific strings?
I would suggest using the Google Translator Toolkit. It supports the various localization files. It also has support for iOS and Android localization files.
Example: For Android you can upload your strings.xml you can select to which files you want to get it translated. It is automatically translated by Google Translate. It uses different colors to display how sure Google Translate is about the translation, and gives feedback about things that needs to be changed in the translations.
You can also use a translation memory. This is a database with saved translations. You can create a personal Translation memory. This contains all the translations you made. You can also use the global TM.
The global TM saves and stores translations from Translator Toolkit users everywhere. Please note that the global TM is available for anyone to see and use.
You read more about it on the support page
It has an editor build in which allows you to change the automatically translated words/sentences. You can export the translations as strings.xml again, so you can use them straightaway in your Android project.
A disadvantage: I don't think it is possible to switch between localization formats, so you have to translate all sentences for both the iOS and Android version.
You can read more about it on the support page
I have a library project that defines the basic structure of an app. I then have several apps based on this library project. To put things in perspective, the library project has about 300 classes (activities, services, data model representation, etc.) Individual apps have about 2-3 classes each, essentially the main activity plus a bit of code customising whatever the library project creates.
The library project contains string resources in several languages (English, Russian, and French at present, but will be extended as translations are ready). The actual apps based on this library project may not require all of these translations. So, is there any way to disable specific languages in the library project from the main app project?
To give a simple example, the library project has English as the main language and also contains resources for Russian and French. The application must always be presented in English (client's requirement). Naturally, I define the application specific resources in English only, but whenever strings from the library project are used, they do come in Russian or French when the device locale is set to one of them. I need to somehow, from the main app, indicate that I only want to use English resources, regardless of the device locale. Is there a way to do this? If yes, how?
I have an android application for one client, and he wants to make a 99% similar app for different country.
Almost everything is the same, only a few bitmaps would need to be replaced, address of API server will change, language file will change, but the code should stay the same, BUT I will need a different package name.
What is a simple way to make a clone of the app that will allow me to make code changes to one version, merge them with the new version (or versions), but keep the package name?
Or should I have everything in one project folder and then write and run some script that will change package names and swap content files? My iOS friend will probably need a few different #defines, but what should I do here, so I can maintain both versions in the future?
declare your original project as library, then create 2 new projects each for one language and let them include original project as library
then you can go ahead and just override bitmaps and constants you need.
this way, if you need any changes in core functionality, you just change your library project, and changes will propagate to both of extending projects
read more about library projects here:
https://developer.android.com/tools/projects/index.html#LibraryProjects
I have an Android app that's downloaded primarily from Android Market (now, Google Play). We made a few tweaks to the source and also submitted to the Amazon App Store to see what sort of traction it gets. I'm now looking for a sustainable way to develop from a common code base and yet build so that I can submit to either/both.
Amazon's store has some restrictions about available APIs, and hence I'd like to conditionally remove/modify features from that version. Since Java doesn't support traditional conditional compilation, and conditionally including files in Eclipse doesn't seem trivial (is it even possible?), I wanted to ask what others are doing to solve this.
Admittedly, I'm no Eclipse/Java expert so feel free to school me.
What I'm looking for in a solution:
Building/debugging using Eclipse.
Static code files, with environment/settings toggles to control what to build.
No duplicate code or conditional logic in code to pick code flow at runtime
Is this something you've solved for Android apps specifically, or for other Java/Eclipse based projects? Suggestions for where to begin?
It's quite easy to do in the newest versions of ADT (version 17), though I do find it makes compilation a bit longer:
Create a new Android project (proj-A)
Go to Project->Properties, select Android, and check "Is Library"
Move all your common code to proj-A, import all the necessary libraries
Create a new Android project for Google Play (proj-B)
Go to Project->Properties, select Android, and add Proj-A to the Library
Repeat #4&5 for the Amazon version
If you have some variables that should be set differently for each sub project (i.e. boolean GOOGLE_PLAY_VERSION to enable Google Play specific functions), you have to create another project to contain these values since you can't have projects that reference one-another in a circular fashion. You can solve this by adding the following steps:
Pull all of your sub-project specific variables into one or more Classes that just serves as container(s) for these variables
Create a "dummy" Java project (dummy)
Config proj-A to add a new Source link to the bin directory of dummy
Add the config Classes in each sub-project with project-specific changes
Profits!
Note that the variables in dummy should not be set as final, otherwise it will override sub-project's setting.
This may seem like quite a bit of up-front work, but has worked quite well for me as far as version control goes.
Edit:
Now with Google's move to Android Studio & Gradle, it may be better to move to that if you are starting a new project if you want to support multiple APKs, see Android dev site's Building Your Project with Gradle#Work with build variants. It definitely doesn't hurt to evaluate that option before deciding.
Unfortunately, it's sort of a convention in Android to change flow at runtime based on what would be in C/C++-land conditional compilation.
Our app has to maintain different behavior for different API levels, so we've created some application-level constants that are initialized statically based on API-level information available to us, and used throughout the code. This is the way that Google does things in their examples (for example, see the ActionBarCompat compatibility library, and in particular the factory method used here).
You could create an interface CustomBuild, and implement it in AmazonBuild and GooglePlayBuild, then use a static getBuild() method to switch functionality as necessary:
if(getBuild().shouldEnableFeatureX()){
doStuff();
} else {
doDifferentStuff();
}
Then all you've got to worry about switching between builds is a line or two of code in the factory along with maintaining which things you want enabled in which versions. Or you could include a different version of a static class CustomBuild for each build.
I'm going to second the suggestion of others above re: switching to something like Maven for building; it should make your life much easier once you have it set up.
I'm also going to say you should make the core of the app a library as suggested above, and have two different modules (one for amazon, one for play store) that depend on the library but each only contain the one custom factory file (or just a static class for each type of build that contains the same "should I do this thing?" methods... once you have the infrastructure it's just a matter of preference).
I haven't actually tried this yet, but it's something I've thought about.
How about using Eclipse's ability to link to files from a directory outside your workspace?
Start with one Eclipse project: for the sake of argument, say it's the Google Play version.
Now build a second project, beginning with asking Eclipse to link (not copy) the source files from your first project.
To develop the second project, add classes that subclass ones from the original project to realize your modifications. For resources, you can use some combination of includes, attribute overrides, and selectors.
Where it's not possible to subclass or extend, then obviously you'll have to just copy the original source file and hack on it. If you're really OCD about it, you can probably just maintain a patch set rather than a whole redundant set of files.
What do you think, will it work?
You may create manually two projects in Eclipse pointing to the same source folders but with different inclusion/exclusion filters and different target directories.
Then two Ant targets using properties to switch excluded files from javac fileset are enough to generate corresponding jar files.
The aim is to get a clean application for each target, without any code from the other one.
With features listed as pluggable behaviors in a property file or XML configuration, your runtime will adapt itself with the addition of menu entries.