Re: NSPropertyDescription userInfo
Re: NSPropertyDescription userInfo
- Subject: Re: NSPropertyDescription userInfo
- From: Jim Correia <email@hidden>
- Date: Sat, 5 Nov 2005 12:10:37 -0500
On Nov 5, 2005, at 12:01 PM, mmalcolm crawford wrote:
On Nov 5, 2005, at 8:29 AM, Jim Correia wrote:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
CoreData/Articles/cdMOM.html#//apple_ref/doc/uid/TP40002328-SW3>
says:
"The easiest way to localize a model is to create a corresponding
strings file—the strings file name is the same as the model file
name, but with a .strings rather than a .xcdatamodel extension
(for example, for a model file named MyDocumentModel.xcdatamodel
the corresponding strings file is MyDocumentModel.strings)."
Since my model was named MyDocument.xcdatamodel, I named the
strings file MyDocument.strings. That didn't work.
Naming it MyDocumentModel.strings does seem to work(*), but isn't
what the documentation says.
Argh! That's a documentation bug. It will be fixed in the release
after next...
MyDocument.xcdatamodel -> MyDocumentModel.strings
Thanks. That will clear things up.
Do you know what is going on with the second problem? Even with the
correct name, and localized name's appearing in the errors, -
[NSManagedObjectModel localizationDictionary] returns nil from the
document's initializer.
Should this be a dictionary populated with the same key/value pairs
as my .strings file? Is this a separate source of localization info?
If I need a localized property name for display in the UI, is there a
framework way to get it? Or must I check the localization dictionary,
and the <xxx>Model.strings files myself using the same fallback paths
as the framework? (In the case of a merged model, how do I backtrack
to the associated .strings files?)
Thanks,
Jim _______________________________________________
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