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