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
