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 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
