[PD-dev] locales and iemgui

[Hans-Christoph Steiner]

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