Hans-Christoph Steiner said : > > I hear you about reusing existing code, but I think there are a number > of code reasons to use msgcat: > - a well debugged and optimized library > - it is a widely used standard, so its well documented (esp. compared to > our code ;) > - there are existing tools to make translating easier > > I'll happily write a script to convert the existing locales to the > msgcat/gettext format if you handle writing the code. :D
ok sure i can understand, i will look into the msgcat stuff next week when my travel finishs and get back into the swing of things. cheers chun > > hc > > > On Jan 6, 2009, at 11:03 AM, [*~] wrote: > >> Hi all: >> >> just a quick reply before i take some days off traveling a bit. >> >> ok, i will look into the msgcat and ths locale stuff you mentioned. >> but meanwhile, i have started porting the locale system in desiredata >> to the new pd-devel, which i think could work nicely too, without >> adding any overhead. its done through a method which will look up >> locale names given by a file, which can be specified in the rc file, or >> as a commandline option. the localed files are just .tcl script calling >> the lookup method with the key value for storing all the terms. >> >> take a look at it and if we really need a change, then we can see how >> best to change it. another reason that i would be more for staying with >> the locale system of desiredata is that we could simply reuse all the >> locale files (with permission) done for it so far, which is quite a >> fair bit(check the locale directory in /src at the dd branch). >> >> my 0.01C:) >> >> cheers >> >> chun >> >> Hans-Christoph Steiner said : >>> >>> Actually, I just found out that the GNU gettext utils for .po files >>> are included in Tcl/Tk in a package called "msgcat". Here's a little >>> bit more on the topic: >>> >>> http://www.gnu.org/software/automake/manual/gettext/Tcl.html >>> >>> .hc >>> >>> On Jan 5, 2009, at 4:33 PM, Hans-Christoph Steiner wrote: >>> >>>> >>>> Hey Chun, all, >>>> >>>> I am thinking that for adding locales to pd-devel, we should leave >>>> iemgui out of it. It is very messy code that has a lot of legacy >>>> use, so that the iemgui stuff would need to have full backwards >>>> compatibility. Instead, I think we should build a new GUI library >>>> that includes locale support. In the process we could make a locale >>>> API for people who want to write their own GUI objects and include >>>> translations. I have almost the whole framework for such a library >>>> finished, its called 'tkwidgets'. >>>> >>>> Perhaps it makes sense to use the standard .po file format for >>>> locales, its pretty simple and would be easy to parse in Tcl. I >>>> imagine there are tools for working with .po files, so then we could >>>> use those. Then init_locale() could read the .po into a hashtable, >>>> i.e. $hashtable($key). My guess is that a big hashtable would be >>>> faster than the current say() procedure, but I could be wrong. >>>> >>>> Or maybe a locale namespace makes more sense, it would just be lots >>>> of variable names, something like: >>>> >>>> namespace eval ::pd_locale:: { >>>> variable file_new >>>> variable file_open >>>> variable file_save >>>> variable file_saveas >>>> ... >>>> variable edit_undo >>>> variable edit_redo >>>> variable edit_cut >>>> variable edit_copy >>>> ... >>>> variable put_object >>>> variable put_message >>>> variable put_numberbox >>>> variable put_symbolbox >>>> variable put_comment >>>> ... >>>> } >>>> >>>> Then to use them: >>>> >>>> $rootmenu add command -label $::pd_locale::file_new -accelerator >>>> "$accelerator+N" >>>> $rootmenu add command -label $::pd_locale::file_open -accelerator >>>> "$accelerator+O" >>>> $rootmenu add command -label $::pd_locale::file_save -accelerator >>>> "$accelerator+S" >>>> >>>> But I suppose it might make more sense to programmatically declare >>>> the 'variable's. >>>> >>>> .hc >>> >>> >>> _______________________________________________ >>> Pd-dev mailing list >>> [email protected] >>> http://lists.puredata.info/listinfo/pd-dev >>> > > _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
