[Proposal] On-the-fly NIB localization
[Proposal] On-the-fly NIB localization
- Subject: [Proposal] On-the-fly NIB localization
- From: Moses Hall <email@hidden>
- Date: Mon, 15 Nov 2004 20:30:58 -0500
Hello, I'm hoping to: (1) propose something I think could be done,
and then (2) get feedback along the lines of "this cannot be done; go
away", "this must be done; sign me up" or "someone's already doing this;
here's the URL".
While Mac OS X has excellent support for localization, the 'directory
per language/dialect' approach to basic, oft-repeated strings such as
"file" and "quit", leads to massive duplication of effort and some
amount of bloat.
What I'd like to see is localization for UI elements in NIB files when
they are loaded. Specifically, placeholders for these common labels,
menu items, and whatnot, that can be replaced with localized strings at
the time a NIB is loaded -- perhaps a call from awakeFromNib. For
example, a standard edit menu having specially formatted placeholders
like "__COPY__"; these to be replaced with localized strings from a
central repository -- and by that I mean a bundle/plist somewhere in
System-land.
In such a scenario, for a well-defined set of labels in my NIB file I
just use this marked up title, safe in the knowledge that a real small
code library, and a real big database, will translate "__COPY__" and
friends into English, Elvish, Arabic, Nunggubuyu or whatever is
appropriate. Granted, the canned text approach doesn't work for error
messages and such, but it's the first step in not having to do all the
work yourself. And it means that once a single person finds the
appropriate translation of the computer concept "File" into Nunggubuyu
(yes there really is a language called Nunggubuyu), all developers
benefit (unless the translation is bad). For large projects with
megabytes of localized strings, this does not net you much. But for
small projects with mostly the "same old boring menus" then you ship one
NIB and get an arbitrarily large number of languages for free, and have
a single point of failure for a subset of localization tasks.
I have written some proof-of-concept code for doing Japanese
localization of menus and windows/view hierarchies. It's recursive and
kind of ugly, but it works. It's encouraging. I'd like to try to answer
the empirical question of how much such an approach will buy you before
it breaks down and you must fall back to an NLG (Natural Language
Generation) system that's smarter.
So that's it. Anybody tried this? Anybody trying it?
I look forward to your criticisms and suggestions.
Thanks,
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