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

Reply via email to