Re: [Proposal] On-the-fly NIB localization
Re: [Proposal] On-the-fly NIB localization
- Subject: Re: [Proposal] On-the-fly NIB localization
- From: Moses Hall <email@hidden>
- Date: Tue, 16 Nov 2004 00:07:29 -0500
Piers Uso Walter wrote:
In many cases, text lengths seem similar enough between languages to
assume that one nib file might be suitable for all localizations. But
this is not always the case. In a suprisingly large number of cases, the
text length differences are so great so that you will have to relayout
your gui to fit the various languages.
You are correct; that's a really big issue for views (fortunately not
menu items). There would be several ways to approach this:
1) Make sure items have enough space for any reasonable
label/title/whatever. This would often be ugly, and would fail in some
cases.
2) Use an alternate NIB-style format that can do "layout management"
which takes a rather different type of AI, and can look horrible (my
colleagues know my opinion of Java's implementations in this direction).
HOWEVER, GNUstep Renaissance http://www.gnustep.it/Renaissance/ looks
rather promising. (Maybe I should be posting to their discussion lists ;-)
3) Do not try to do automatic localization for views. (No fun!)
But still, you would have to be careful about where to use the
standardized translations in order not to loose language-specific
subleties. E.g. most languages have identical words with different
meanings, that will be turned into different words upon translation.
This goes both ways, e.g. word A1 can mean either word B1 or word B2 in
a different language, depending on context, while at the same time word
B3 can mean either word A2 or word A3 in the first language. Of course,
there are also much more complicated semantic subtleties than those in
this example. Placeholders have a hard time dealing with such issues.
That's where such efforts get into a kind of ontological engineering.
Granted it's domain-specific over a small domain, but there are still
the issues you point out. It is true that a menu labeled "File" probably
would not have the same semantics as a button labeled "File". (The
latter could mean "file the selections somewhere" whereas the File menu
is pretty much semantically bleached [is it a noun or a verb?]). Or,
heaven forbid, "File" on a tool bar in a woodworking simulation app!
(Right next to "Hammer" and "Band-Aids".)
As such, a label scheme should perhaps contain "path" information such
as (in my yucky markup) __MENU_FILE__ to indicate it's "File" under the
"Menu" domain.
Anyway, in case you're wondering this is more a proposal for a research
project, rather than an invitation for Adobe to use my source code in
their next release of Photoshop ;-) I am asking "how much could be done"
and expecting to fail, and learn, and thus not fail completely.
Thanks for your comments,
Brian 'Moses' Hall
www.blugs.com
_______________________________________________
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