// en.lproj
“hello” = “Hello”;

// it.lproj
“hello” = “Ciao”;

// sp.lproj
“hello” = “Hola”;

The basic approach is to use the english word as the key and assign it different values based on the localization file, but we can be more cryptic and use our custom conventions, for example by assigning incremental keys like: “k1″, “k2″, “k3″ and so on. As last step, we can automatically read the right localized string version at runtime (based on user’s language setting) by using macro (NSLocalizedString, NSLocalizedStringFromTable, NSLocalizedStringFromTableInBundle, NSLocalizedStringWithDefaultValue) or class methods available in Apple’s framework. The simplest way to do that is to use the function NSLocalizedString(), which accepts two arguments: an NSString representing the key we are looking for and a second optional argument which has the mere purpose of serving as note for developers by trying to describe string’s context (*), for this reason this argument will be “nil” the most of times:

Although this approach is very simple, it’s not recommendable in my opinion, because it doesn’t provide a way to handle missing keys and if a key can’t be found, it will print that key literally (and in case of a not human readable key like “k-15″, it would be very annoying for the user). Thus, a far better option is to use the NSLocalizedStringWithDefaultValue(), which accepts 5 arguments: an NSString for the key, an NSString for the table, an NSBundle reference, an NSString for a fallback string’s value, and an optional NSString for a comment (like NSLocalizedString()). The table argument refers to the name of .strings file (without extension), in fact we are not limited to “Localizable.strings” but we can create as many .strings files we need (“Menu.strings”, “InfoPanel.strings”…). “Localizable.strings” is only a conventional name used to specify a default file for localization that can be loaded without specify its name (NSLocalizedString() can read only that file). The bundle is a reference to the NSBundle where the .strings file is located (usually the main bundle).

It’s also possible to use bundle’s method localizedStringForKey:value:table, which accepts an NSString as key, a second NSString as fallback value, and a third NSString for the table (or nil if you are lazy and want to use “Localizable.strings” without specifying it) :

An important point to understand is how localization process works, that is which steps are involved at runtime on the device. As far I know (by doing several experiment using iPhone simulator), the process is the following:

1. code is executed and a request for a localized string is found
2. the system try to find the .strings file of the current locale (according to user language settings). The NSString represenitng current locale can be found using:

3. If the file is found, it will search for the requested key and it will return it’s value if found or a nil otherwise. If .strings file can’t be found, the system will try to find others .strings file sequentially, using preferredLanguages‘s NSArray:

and it will stops as soon a file is found, by returning key’s value if found or nil otherwise.

So, considering the simple “hello” localization example into english, italian and spanish, our @”hello” key will be successfully translated if we use one of the three locales (en, it, sp) and it will be printed in english for extra locales (like german, french and so on).

Finally it’s also possible to generate strings file automatically from the source code by using Terminal’s command genstrings, see here for details: http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/genstrings.1.html

* the comment parameter is also used to automatically generate a comment (/* comment */) in .strings files using genstrings

Any comment and suggestion is really appreciated! Thanks

Finally, it seems that double click is completely ignored by Firefox 3.6 on Mac OS X, but fortunately this seems to been fixed in the last release (3.6.3)

• getHours()
• getMinutes()
• getSeconds()

So, in order to take advantage of these useful methods, all we have to do is initialize a “fake” date using the amount of seconds we want to “split” into hours, minutes and seconds. The Date class has several OPTIONAL arguments that can be specified during its initializations, these are:

• year
• month
• date (day number)
• hours
• minutes
• seconds
• milliseconds

Because theme all are optional, we can create a date object by specifying only the know arguments (in our case seconds) and by assigning null or zero to the others:

Then by calling getHours, getMinutes and getSeconds we will obtain what we expect:

Not sure about the result? Let’s test it:

60 * 60 * 2 = 7200; (seconds contained in 2 hours)
32 * 60 = 1920; (seconds contained in 32 minutes)
7200 + 1920 + 17 = 9137; (original seconds!)

To open Xcode console you have to choose “Run -> Console” from the toolbar (or CMD+SHIFT+R) and after a “Build and Run” (CMD+Enter), you will see your message appear in the console.
Testing applications while developing using PhoneGap and Xcode, is an intense activity, because errors are not automatically notified (like in FireBug or similar), so it’s really important to make use of try/catch/finally blocks and logging calls:

Finally, in order to avoid problems related to Xcode cache, I suggest to always clean the cache by running “Build -> Clean” from the toolbar (or CMD+SHIFT+K) before doing a new build and eventually remove the application folder under “/Users/{your-name}/Library/Application Support/iPhone Simulator/User/Applications/{app-number}”.

Then I changed all jQTouch CSS, to reflect this approach (you can see the wrapper as a sandbox):

…and finally I changed jQuery selectors inside JavaScript code:

It’s also possible to solve the conflict by changing SpinningWheel code in order to put the dom node inside active jQTouch pages, but the problem of potential incompatibilities will remains. A CSS declaration, except reset statements and other rare cases, should NEVER refers directly to a whole set of nodes (ie: ul { color: red; }), but to a node type contained by a wrapper/sandbox (ie: #foo ul {color: red; }), thus conflicts will be avoided.

that true should be a parametric value which developers can set to true or false. Why forcing it to true???
I’m really disappointed :(

It’s important to notice some points, first you MUST write an “header” using the comment syntax “/* */” into which you MUST declare at least 2 parameter: the “Menu” path (you can nest several menu items by writing several “>”) and the “DOM” package (which allows you to access specific objects like “editors“). You can write several js functions, but you must provide a main() function, which is called automatically by Eclipse once you launch your script, otherwise you can call the main function as you like but you must then provide the “OnLoad” param in the header, specifying which function will be called.
To define a shortcut you can use the “Key” parameter and define your own keys combination by choosing among the four modifiers: M1, M2, M3, M4, that are a platform-independent way of representing keys (these stand for ALT, COMMAND, CTRL, and SHIFT). The strange (at least to me) parameter “Kudos” is used to declare the author of the monkey script.
To test my little script or create your own, you have simply to create a new project into Eclipse by calling it as you like (ie: “custom-extensions”), then create a “scripts” folder into which you will save your .js files… that’s all, try yourself and enjoy :)

This is how it looks:

eclipse monkey script menu

ps: I’m going to explore the Monkey Script API in order to write more complex and useful extensions :P