Restrict i18n+l10n to players and tools?

[mmitch]

Current state

• gbsplay (and to some lesser degree xgbsplay) use localized messages in their output
• gbsinfo uses localized messages in its output
• libgbs is localized as well

Current issues

With the players and interactive tools, l10n is good and useful, but I don't think libgbs should use l10n:

• libgbs should not directly write to stderr:
  • if stderr is redirected or used for something else, libgbs will mess it up
  • if stderr is closed, it will crash the whole process when trying to say something like "file not found"
• the user of the API must have l10n support installed (?)
  • I'm not sure on this one and if a lib built with l10n support would work on a system without l10n support.
  • libintl stuff on the Windows builds was quite a hassle, we don't want to put our users through this.
  • Worst case is that we would have to provide two versions of the library, one with l10n and one without.

Proposal

Don't use localization in libgbs.

• don't write to stderr or stdout in libgbs
• don't call the intl... functions
• refactor error handling in gbs_open() so that something like an error enum is returned to the caller
• optionally provide a thin wrapper outside of the API that returns localized strings for these error messages
  • if libgbs with l10n baked in also works on a system without l10n support, this gbs_get_errormessage() could be included as a function in the API – but we could still refrain from using stderr/stdout directly
• this looks like we might get different compiler and linker flags for the API and the tools, so we should perhaps split the source into different subdirectories
  • this might be a good idea regardless of any l10n issues ;-)

Please discuss!