Hi Frédéric, Thanks for taking a first look at this. As a quick note, we'd like to keep all development email on chromium-dev. We think of ourselves as one team working on a single cross platform product.
As for your idea, I think it's the right approach for getting something up and running quickly. It's a bit more complicated in that there are actually multiple .grd files (3 right now) that generate 3 .h files and 3 .rc files on windows. The resource compiler in Visual Studio takes all three .rc files to generate one data library. So there may need to be a second pass that merges the output of GRIT into a single file. This would probably happen in the SConscript file. Some other general questions: 1) Should we actually store the strings in a shared library or should it just be a data file that we read/parse on startup? 2) Should we perhaps try to output .po and write a gettext wrapper for loading strings (maybe we could use rc2po [1])? I haven't used gettext before, but perhaps there are benefits of using an existing tool (e.g., making it easy for people to contribute translations). tony [1] http://translate.sourceforge.net/wiki/toolkit/rc2po On Sat, 6 Sep 2008, Frédéric wrote: > Hello all, > > Since there is nobody on IRC to hear me, i'm writing here on this > mailing list... > > So after having a look at this issue (http://code.google.com/p/ > chromium/issues/detail?id=1529) > Here my first idea : > From the grd files, generate an header defining all the IDS (like it > is done on windows). > Next generate one shared library per language. > This library is loaded via the dlopen - as it is done on windows - > and retrieve a pointer on a function which return the string > associated to the ID (method declaration can be like wchar * > GetLocalizedString(int message_id)). > > AFAIK there is no LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE flags as on > windows when loading library :-s. > > The main issue with this is that since we are loading a shared library > and using a function pointer, a malicious shared library can do what > they want in the method GetLocalizedString... > > One another solution could to generate a hashmap<ID,string> and > retrieve pointer on this data. In this case no function is executed > but in any case the library "constructor" will be call at dlopen > > PS : i''ve done some prototyping (a ugly hack on the grit tools to > generate the c files) with a stupid main files loading the shared lib > and asking for a string... > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
