With the fix on bug 397811 we can now enable/disable the Mac OS X address book with an menu item inside the File menu. This item is named "Mac OS X Address Book". Currently we only have this feature on OS X but how it should be called when this feature is also implemented for other operating systems? In such a case we need different strings for each one. To simplify the usage we should use the same name for each OS. See the API reference for the other main operating systems: http://msdn.microsoft.com/en-us/library/ms629440(VS.85).aspx http://api.kde.org/4.x-api/kdepim-apidocs/kaddressbook/html/index.html http://library.gnome.org/devel/libebook/stable/ IMO it's worth to do the renaming.
I don't know about mac, but at least on linux I wouldn't have had any idea what the "system address book" is - and reading those I still don't... as one can use both kde and gnome at the same time. (Wouldn't have known on windows either.)
We should do what makes the most sense from a user experience point of view. I don't have a particularly strong opinion about what that is in this case. If that requires per-platform strings, we should accept that cost.
(In reply to comment #2) > We should do what makes the most sense from a user experience point of view. standard8? My first thoughts - documentation and user assistance might be clearer if we call it something different on each OS, i.e. the name as it is known for the OS - for OS based message search, we are not using a generic name, eg on TB System Integration options panel for windows we say "Windows Search" In short, I'm with magnus
Having thought about this, I think that the "System" address book can be unclear to users as to which address book it is. For instance, I don't know if Windows even has an address book that everything uses - on older versions I seem to remember there were two floating about, one in outlook and possibly one system-ish like in accessories or something. I think that explicitly saying which address book we're hooking into (assuming we do know) is probably best, and we'll review the new wording if/when we add new implementations. So I think this should be wontfix for now - however I'm quite happy for Blake or Bryan to overrule me on this.