Re: Bindings and localization
Re: Bindings and localization
- Subject: Re: Bindings and localization
- From: mmalcolm crawford <email@hidden>
- Date: Thu, 11 Nov 2004 21:24:31 -0800
On Nov 11, 2004, at 5:42 PM, Larry Gerndt wrote:
All that said, it's not clear just how much value bindings per se
would be in
many localisation tasks. Part of the effort is typically ensuring
that the
user interface is satisfactorily laid out. Using bindings, or any
other
mechanism (in the absence of any other tools support), to dynamically
localise
the interface at runtime makes it more difficult for translators and
for
designers.
This is true, but with careful UI design, it might be possible to make
the
buttons and fields large enough to accommodate the string in any
language.
And if that be the case, then the translator's job becomes *much*
easier
because he only has to edit the strings files.
Again, not necessarily; consider "Tram Stop" vs.
"Straßenbahnhaltestelle". You would probably want different window
sizes for each label. Moreover, you lose context. A translator may
need to know where a string appears in order to be able to determine
the best translation.
I thought about the value transformer, but I think the problem there
is,
you'd have to bind each text field to a specific string (the key) in
File's
Owner, which would bloat that class with accessors for every single
string
key, or am I misunderstanding something?
If you wanted to do the whole UI, I would envisage a
"LocalisationController". You would probably have a different
controller per table, and you hook it up in a way akin to a user
defaults controller.
I want the text field's current value (as entered in IB) to be the
key, but I see no way of passing that to the transformer.
No, you can't readily do that.
For what you appear to be envisaging, however, I'm not sure that
bindings per se are the right solution. It's more an extension of IB
itself, to allow you to specify the key (and table?) for attributes of
various controls...
mmalc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden