Heya, my idea would be that we copy the Windows approach 1 to 1.
We change the tool so that it does not output .rc files, but only a header on non-Windows. In this header we define the strings as constants: Advantage: EXTREMELY FAST. No overhead. We can overlay LoadString with a Macro and we get the same performance as with static strings Disadvantage: Only one language per build. Option b) We change the tool to output a source files which contains an array of arrays of strings. ( array of array of array of chars if it helps you) . like: char * _locale[NUMBER_OF_LOCALIZATIONS_IN_BUILD][NUMBER_OF_STRINGS]; and also a global variable: unsigned int _currentlocale; Then we overlay the Win32 API functions for string resources with macros in the header. I would propose a macro _STR(x) ( _locale[_currentlocale][x] ) which always points to a given string ( for unit testing we can add an assert macro in there) Then also a macro to change the current locale etc. Advantages: Portable. Compatible even to ANSI C if you want to use it somewhere else. Fast . NEarly the same performance like static strings. Easy to use. Each string gets a define constant based on XML and that is it. Bug free . No missing files, everything is compiled in. Disadvantages: All localizations reside in the .exe... On Sep 9, 3:19 pm, Grim <[EMAIL PROTECTED]> wrote: > There is a cross platform solution for translation strings based on > int/ID called catgets[1] (now available as a part of gettext for > backward compatibility). But it isn't used anymore since the extra > work to keep track of those string IDs is just a waste of time. If > that time is going to be wasted anyway (if Windows requires it) > catgets could be used on Unix. > > The whole point of using gettext is to save the developers valuable > time. And that point is equally valid on all platforms IMHO. If the > executables get slightly bigger and the lookups get (theoretically) > slightly slower it is of much less importance. > > [1]http://www.gnu.org/software/automake/manual/gettext/catgets.html --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
