Sorry, I would hold off on this for now. On Windows, it seems like using gettext is a step backwards since it's more code for no real benefit. Also, on Mac, we might want to use the native string format. Basically, we need to figure out if we're going to use a cross platform solution or whatever makes the most sense on each platform.
tony On Mon, 8 Sep 2008, Frédéric wrote: > > IMHO using gettext is better since gettext data are more data files > and have less security probleme than a shared libs and it widely used > on linux desktop... > > My main remark is that gettext relies on a string (english one > usually) to retrieve the translated string (it can be see as a > dictionnary key ;-) ). > So relying on gettext will need to first create link between the IDS > (int) and the english string and next using the gettext to retrieve > the translatation : > Of course it is not so bad because you always have a string ;-). > > I will restart my prototype to use the gettext stuff (but have lot of > work for my real job so :-s ) ... > > PS : Regarding the topic of the mailing list, if you want to have only > one mailing list for all dev, maybe we should start subject dedicated > to one platform with the platform title between bracket, for example : > this thread should have "[linux] About the Issue 1529: port build/ > localized_strings/SConsc ript for linux Options." as title : it's > easier to filter in my email client ;-) > > > On 8 sep, 01:17, [EMAIL PROTECTED] wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
