Ok, but on linux platform there is not lot of choice ;-) For backup purpose I put here y result : ============= I tried the rc2po (the dev version since its is not already release) and I have only generated the gettext file to be loaded... For information, here is a first explanation of how its working : - go inside your directory with all your webkit strings rc files
since rc2po seems to have a bug with UTF-16, for demo purpose,create a rc dir and convert all files to utf-8 inside this dir : $ mkdir rc $ for i in *.rc; do iconv -c -f UTF-16 -t UTF-8 $i -o ./rc/$i; done now create a po dir & call the rc2po $ mkdir po $ rc2po --charset=UTF-8 -t rc/webkit_strings_en-US.rc rc po and 'compile i' into a mo dir : $ cd po $ for i in *.po; do msgfmt $i -o `basename $i .po`.mo; done Now you have all your mo to be loaded by gettext ;-) On 8 sep, 22:39, [EMAIL PROTECTED] wrote: > 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 -~----------~----~----~----~------~----~------~--~---
