Internationalisation

[Scott Rossi]

> 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: scott at tactilemedia.com
Web: www.tactilemedia.com