Re: Localization good practices

Hi Richard,

R Frith-Macdonald wrote:
>
> While locale specific files may provide the best possible UI, it's a 
> lot more work for the developer/maintainer of an app, so it's 
> optional.  Carefully designed interfaces can generally be made to work 
> with a small amount of text and be designed so that the necessary text 
> will look good in all (or almost all) languages.
>
> So I would say that, while the common practice is to have a single 
> gorm file and a set of strings files (one for each locale), that does 
> not mean that there is anything wrong with also having different gorm 
> files for different locales.
>

You are correct, it is not "tecnically wrong" to have more localised 
gorm files, I just say it is inconvenient, a single change needs to be 
replicated and things can be error prone.
It is also true what you say, certain translations  could require 
interface change, all strings need to be tested.

If the app exists also on the mac, then the same work needs to 
replicated for NIB files.

In case probably a mixed approach could be done, split the app in more 
GORM/NIB files and only customize the difficult ones and thus restrict 
impacts

Can a string file localise a gorm file without code?

Currently the only proven way I know is to Make a Gorm and NIB file and 
have an IBOutlet for *all* items (menus, buttons, etc) and the 
explicitely in nib loading set titles of all elements using localized 
string. This approach works on both NIB and GORM file at the same time.
Or is there a way to have gorm loading do that automatically? and share 
the keys with NIB too?

The advantage of this approach is that if an element is untranslated, it 
will at most appear in the original language (English) but functionality 
is preserved. With multiple gorm files something could be missing (or 
wrong connected, like in the Addresses example).

Furthermore of course the string file contains other output.

Riccardo