[PD-dev] locales and iemgui

*~ chun at goto10.org
Mon Jan 12 05:01:51 CET 2009

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.



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

More information about the Pd-dev mailing list