On Tue, 14 Jul 2009 21:59:28 +1000, Lex wrote:
Hi All,
A question for the Geany translation/intltool expert.
Tell me if you found one :).
I have been creating a Latex filetype file for the build-system branch which contains labels for the menu items which need translation, "View PDF File" and "View DVI File" for example.
The filetype is read in a locale sensitive manner and should load any translations that are in the file, and my reading of the intltool documentation leads me to believe that it should be able to extract marked entries from config files like filetype.latex and include them in the translation process alongside the source code strings and then merge the translations back into the config file.
What I can't work out from the documentation is how do I tell intltool to do it. I read it as it will include desktop.ini and other known files but it doesn't tell how to include other files. X-S
See the geany.desktop.in file. This is exactly what you want: the .desktop.in file contains _Foo=Center entries. The leading underscore indicates that this string should be localised when processed with intltool. Intltool will recognise these entries and replace the value with found translations. The result would look like: Foo=Center Foo[en_GB]=Centre Foo[de]=Zentrum Foo[fr]=Centre ...
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.
IIRC this all is part of the desktop entry spec at fd.o, but I might be wrong. Anyway, it works this way and we are using this in our .desktop.in file since ages. One more note about the .in: the raw file has the _Foo=... keys and then it get processed with intltool which replaces the underscore prefixed entries with the localised ones and so the file becomes .desktop.
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.
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. 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.
What do the others think?
Regards, Enrico