> Consider the following for the brainstorming only. Cocoa, Apple's > Objective-C application framework, has the most elegant > internationalization method I've ever seen in a programming > environment. It might not even be applicable to Revolution. However, > maybe people will want to dig deeper and get some ideas for the ideal > way to do it in Revolution. > > Cocoa applications that support Internationalization are automatically > and fully translated into the appropriate language at run-time,. > Everything can be Internationalized, from graphics to on-screen text to > messages and programmatic content. Messages coming back from the OS are > internationalized. Date, time, and currency formatting are easily > formatted to user's international preferences. > > ... > > A nib file is an archive of user-interface objects created by Interface > Builder.app. It contains the layouts and connections among Windows, > Views, Buttons, etc. In contains the entire GUI, except parts which are > created programmatically. When the app runs, the "nib" file is > connected to the app itself. The app has "outlets" which are connected > to objects in the nib file. The nib file objects have "actions" and > "delegates" which are connected to objects and methods in the app > itself. So the UI components and the app code are cleanly separated, > but glued together automatically at runtime.
The above scenario worked well for us in our multi-language projects (sans the NIB files). Our setup is pretty much as described: a resource folder which contains a subfolder for each language. In each language folder is a master text document that was professionally translated and contains every localized portion of the project UI, tagged by an id: <1001> This is a headline. </1001) We found the above to be a good technique since using a start and end id tag allows us to easily parse multi-line/paragraph blocks without having to resort to complex lineOffset routines. In the stack, selecting a language reads in the appropriate localized text resource document, and the UI is localized via script upon every preOpenCard handler by simply setting the text or label of each control to the id of the appropriate localized text. It may sound complicated but it's actually quite simple. In the root level of the resources folder we place any items that are common to all languages in a "common" folder: graphics, sounds, etc; any language-specific resources are placed in their respective folders. Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design Email: [EMAIL PROTECTED] Web: www.tactilemedia.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution