I'm not sure that makes it any easier. Yes, we can check for things like Capital C Cordova, vs lower case c cordova, but it makes the actual coding more disjoint IMHO. Generally the strings are pretty specific to the plugin. And, having them all in a separate file makes it harder to separate out the plugin code. I think what we really need is better testing mechanisms to catch these type of errors.
my two cents, -becky On Fri, Apr 13, 2012 at 2:58 PM, Shazron <[email protected]> wrote: > We currently have to write out JavaScript from Objective-C, and these > strings can't be checked easily all in one place (note the bugs found > today slated for 1.6.1) > > I'm proposing we either use: > 1. NSLocalizedString [1][2] where the strings are in an external strings > file > 2. an Obj-C templating [3] solution that we need to create, > essentially the same as 1 but with more features, although that's more > complex > 3. Move all the JS strings into an Obj-C file as string constants > > Items 1 and 2 require the .strings file to be in the user's > application potentially (I haven't tested whether loading strings from > the current framework bundle will work) and may be an upgrade > nightmare (and we don't want users to edit them). > Item 3 might be easiest, since it will all be baked-in. > > My preference is 1 (if the framework bundle loading works), then 3. > > > [1] http://www.cocoadev.com/index.pl?NSLocalizedString > [2] http://cocoawithlove.com/2011/04/user-interface-strings-in-cocoa.html > [3] A bit of overkill though, Mustache for Obj-C: > https://github.com/hiddenmemory/Tipi >
