Some notes on the differences between these two concepts.
- Logs are read by administrators and maybe even users, while tracing output is strictly for developers and maintainers. Thus localisation is relevant for logging but not for tracing.
- For enterprise class applications it is probably desirable to be able to change logging levels without forcing a restart. For tracing on the other hand being able to change trace level with a mere configuration file change and a restart is manna compared with the recompiles required by C/C++ etc.
Out of interest, with MMOG platform development, we've tended to see a different pattern:
- the "users" and admins are hardcore developers already (unlike many J2EE developers, for instance), and so everyone (both end-users and the original developers / vendor support team) wants to see the same stuff, i.e. everything
- very few things that happen are worth turning on logging after the event. If logging wasn't on when it happened, it usually isn't going to happen again anyway, unless you are a developer working on a private build that hasn't passed the test suite yet (in which case you often have recurring bugs). So, it seems to work the other way around: customers are generally happy with restart and edit log config files, whilst core developers want mid-runtime re-configuration.
(although, of course, some customers end up doing extensive enough development that they are hugely customizing the enterprise platform, and so move towards the postiion of the core develoeprs. Unlike with J2EE etc, customer-customization of the platform is not only easy but actively encouraged)