On Thu, Jan 10, 2013 at 7:25 PM, Hans-Christoph Steiner hans@at.or.atwrote:
On 01/10/2013 12:36 PM, András Murányi wrote:
On Wed, Jan 9, 2013 at 5:35 PM, Hans-Christoph Steiner <hans@at.or.at wrote:
Since Tcl handles all of the changing of English strings to the chosen language,
Does it mean that there are no GUI strings in the C code?
There are GUI strings in the C code, but in order for you to see them, they are sent to pd-gui, the Tcl process. If you're running in -nogui mode, there will be no translations since all the translations are handled in Tcl.
Ah! BTW, would it take much to have gettext working on the C side too?
it is theoritically possible to do in a plugin. The key problem is that the translations are loaded (load_locale in pd-gui.tcl) before the plugins and Tcl's msgcat, the library for the translations, provides mcload, but no mkunload.
To be exact, not even mcunload would be necessary, just a way to reload strings according to the new locale. Unfortunately, this functionality is missing from TCL (there are some feature requests in the tracker that target it, though). So, to effectively change the GUI language, Pd needs to be restarted. Do
we
wish to have a language selection option in the preferences, which
writes
its setting somewhere on the disk, and then load_locale would be changed
in
a way that it takes a look at the saved setting before defaulting to the OS/env language? (my vote is: no)
That would be possible. I would be willing to accept such a patch if it was well tested but I'm not going to write it :)
.hc
Well I shall not take on more things (but to carry on with things that I've already started), but... :) This stuff would actually be another driver for me to dive into the prefs system... and eventually evolve that a bit, too*.
- right now the guiprefs system is geared towards the recentfiles list, and
it might need some mods to serve other purposes as well.
András