[Geany-devel] intltool usage question
enrico.troeger at xxxxx
Tue Jul 14 19:35:59 UTC 2009
On Tue, 14 Jul 2009 21:59:28 +1000, Lex wrote:
>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
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
And GLib's keyfile parser can read these entries as well, i.e. it
returns the value for the current locale when using the
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
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?
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the Devel