On Nov 3, 2007, at 3:44 PM, Christiaan Hofman wrote:
> I don't think it's necessary to run it on headers. I think the only
> possible use could be to catch macros including NSLocalizedString,
> but I don't think they occur in any header.
I think so too. I'm going to be changing it in the project here
shortly.
> As for vendorsrc, all
> localized strings for the Omni frameworks should be in the special
> tables. Other 3rd party sources could contain NSLocalizedString, but
> a quick Find does not show any. Subprojects can also contain
> NSLocalizedString, in fact BTParse does. So I think that one at least
> needs to be parsed (or can it be contained in its own Resources?
I think the frameworks should all be doing their own bundled
NSLocalizedString lookup like the Omni apps, or else they try a lookup
from the main bundle. I think that's the point of Omni's redefine of
NSLocalizedString in macros.h, anyway, but I've never handled that
appropriately in our frameworks.
> I don't know precisely where localized strings in frameworks look). So
> I think we can safely leave out most of vendorsrc. Would it be
> possible to move BDSKErrorObject.* to ./BTParse/ and just include ./*.
> {m,h} ./BTParse.{m,h} and ./inputmanager/*.{m,h}, I think that covers
> all occurences of NSLocalizedString.
The inputmanager strings shouldn't be included in BibDesk's table
either, since those will be looked up in the containing app's bundle
(I think) if NSLocalizedString() is used. That one should look up the
bundle based on identifier.
--
adam
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
