Hi Enrico,
Thanks see below.
And GLib's keyfile parser can read these entries as well, i.e. it returns the value for the current locale when using the g_key_file_get_locale_string() function.
my build-system branch build.c uses this for system filetype files to read menu labels
In theory, we could apply this workflow to the filetype definition files to get localised build menu labels. But I don't really like this idea as it would mean we need to rename all these files and add rules to our both build systems to process each of these files with intltool.
This workflow is what I was asking about, I have a filetype.latex.in with the appropriate key marked but intltool ignores it, is there something somewhere else that needs to be set to make it work?
Do we have to do it for all filetypes files or only those which need it (latex initially).
If only the required files need to be renamed then it could migrate over time as patches were submitted by individual language users and no big upheaval needed. Note that labels in the filetype file are only needed for filetypes where the default labels of compile, build and execute are inappropriate or which add extra commands.
The new settings are in a different section in the filetype file and the old filetype file settings are still read if no new section is found, I wasn't even going to change most of the filetypes files to the new format.
I'd even rather prefer to have unlocalised English labels by default since the user can change them now as necessary though this isn't really nice too.
Well this is what happens by default even if there are no translations. I only put the capability in the software because localised labels are nicer, but if it turns out to be *way* too much trouble then it will continue to work fine as is.
A third possibility would be to list the necessary translatable strings for the labels in some source file like src/build.c so that the gettext translation system will pick them up by default and they get localised by the busy translators and then after reading the label texts from the filetype definition files, we feed them to gettext() to get the translation before displaying them. This would be probably the easiest way while it feels a bit hackish.
Desperatly trying to avoid this :-(
What do the others think?
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel