[PD-dev] locales and iemgui

[*~]

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
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>