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