Okay, I have a plan for multiple language support in my app, including translation of RSS feeds (that are English to start with). I'm posting to get feedback and to share (what I have so far for) my solution. I have added code in BT_device.m, BT_device.h, and BT_strings.m to retrieve the language code for the device and store it in deviceLanguageCode ; in BT_strings.m I added code to supply the language code as a merge field to URLs. I am using Yahoo Pipes to read and translate RSS feeds and output a new RSS feed. My example feed is here : http://pipes.yahoo.com/pipes/pipe.edit?_id=ad6141dfb4b09e95d7f7fc0b9060d106 The example pipe uses Microsoft Bing's translate API to translate the title of each item in the RSS feed; the language I want to translate to is passed via the merge fields in the url for the RSS feed in the format: big-long-URL&languageCode=[deviceLanguageCode] The pipe takes in the language code through the user inputs and then goes and gets a public feed that is English and translates the feed titles to the requested language. This works, and the code changes I made worked to pass the language code. (I can share that code, if anyone is interested.) I know that I have read elsewhere in the forums how to supply alternate language translations for hard-coded phrases in the Buzztouch base, but does that solution also extend to the titles and descriptions we give to our screens? Or is that something that can or has to be handled with JSON files, stored online and translated on the fly also?

Wow, ambitious and creative for sure. You're right in that the values you enter in the control panel (in the database) have nothing to do with the Language.strings file in the app. That file is used for miscellaneous alerts, prompts, errors, etc. We've tried to come up with some ways to allow you to enter multiple values in the control panel for multiple languages but never came up with anything other than a complicated mess! Your idea of passing the devices language to a backend makes perfect sense. I can imagine doing something like... a) Saving the devices lanuage to a global variable (like you did) b) Creating multiple BT_config.txt files, one for each language you want to support. c) Loading a different BT_config.txt file with the app refreshes. The config file that loads would come from the URL you 'pointed to' with the language setting merged. This means you'll probably do some processing server side to produce the right config.txt file after learning the language in the URL. The Yahoo Pipes / Translation thing is super creative and it will be interesting to see how this works.

going to link these issues together. http://www.buzztouch.com/forum/thread.php?tid=28E05367DE2AC6F1AF21D75&status=&searchInput=rss&sortColumn=FT.dateStampUTC&sortUpDown=DESC¤tPage=1&doViews=1 The Pipes Translation works fine, until I tried to implement one translation pipe to be used for all of my RSS feeds. That is when I ran into trouble with the RSS feed being passed as a parameter to the Pipe, which is also being read as an RSS feed. The translation pipe works in browsers, but I see a problem once I try to put that RSS feed into the RSS reader in Buzztouch.

@rgtichy could you share your code for retrieving the device language code with me? I'm going to do some experiments following David's recommandations.

Sure! Here's what I did/accomplished: In device.h and device.m the information is collected about the device that the app is being run on. So I added a new merge field value called deviceLanguageCode In device.h in the BT_objects folder in a project, I added the 2 lines marked RGT RGT */ In device.m, I added 3 lines marked RGT RGT */ In BT_strings.m I added code to substitute my new merge field name into URLs, which is the job of the BT_strings routine; there is only one line, also marked RGT RGT */ Here are links to the 3 files: https://docs.google.com/open?id=0B-6uPnuuu30yOTgxMGQ5OTYtNDgyNC00ZTRlLWI1YjctNGVmNzdkOGFiZGFm https://docs.google.com/open?id=0B-6uPnuuu30yZjRmNzQwZTAtZGZlMi00MjJiLWFjYzEtYzhmNTQzYTNiNDI0 https://docs.google.com/open?id=0B-6uPnuuu30yYzNhOWE0M2MtZDMzNC00MzgwLThmYzEtYTZmMDMzMzJjN2E3 There are actually a lot of different things that I think could be added into these routines to expose more information about the user's device.

I just tried out those links above, and they do work, but only to download the files, not to view them online. Just open them in textEdit and search for RGT RGT to find my lines of code. I guess I need to learn more about web file sharing, I had hoped Google docs would let users specify to just view them in the word processor app

Thanks a lot. I will share my results.

For sharing a Google Docs file, in the menu/file choose Publish on the internet. See also: https://support.google.com/docs/bin/answer.py?hl=en&answer=183965

interesting, do you know exactly how it works? They talk about publishing as producing a lightweight HTML version, but will it do that for non-google docs formats? I could have made the file in the word processor I guess, it wouldn't have hurt anything. My real thought was to not publish it where the rest of the world could get BT's code, without being a member at BT; hence the link only available inside the forum and the availability to anyone with the link to view (which is slightly inadequate as security, but politely attempts; anyway BT is sharing their code with all of us anyway.).

The Google Docs viewer supports a number of file types, not including .m or .h files. Quickest way to get it into Google Docs and sharable is creating a new text file and copy the contents and then publish on the internet and send the produced link. It is not really public that way. You need to have the link to view the file. test: https://docs.google.com/document/pub?id=1nIpfN86s-TIpDoBus0zIkH9HyXmZTq6ewmAUVcMjuPg supported file types; http://support.google.com/docs/bin/answer.py?hl=en&answer=1189935

I agree. Have you had any other success with multilingual support, yet? What do you think your design plan is going to be? A good design could be used to remake about half of the plug-ins for BT server to make them multi-lingual. In my mind I see a couple of ideas that could be incorporated; a server that supplies JSON translated to the device language for each screen would be useful, but I think supporting a hard-coded list of language translations for menu choices would be essential too. So it should work in a sort of fall-back way: 1) is it the app's native language? 2) is there a specific translation stored already?, 3) translate it using the cloud resources. For me, the question is whether #2 is stored on the device or stored in the cloud. In the cloud seems easier, but then offline use is reduced. Of course, offline use is near obsolete.

Imho a solution for the BT-server involves separating the jsonVars from the table bt_items into an additional language table, where the item_id is combined with a lang_id and a language specific jsonVar. In this jsonVar you change the namings and references to online or offline documents as needed per language. For now this can be done in Xcode the way David suggested with the help of your deviceLanguageCode. I will try that.. soon. For the names of menu's and other language sensitive namings the hard coded list would do - stored in the appropriate language folder. Keep you posted.