Hi Enrico,<br><br>Thanks see below.<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
And GLib's keyfile parser can read these entries as well, i.e. it<br>
returns the value for the current locale when using the<br>
g_key_file_get_locale_string() function.</blockquote><div><br>my  build-system branch build.c uses this for system filetype files to read menu labels<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
In theory, we could apply this workflow to the filetype definition<br>
files to get localised build menu labels. But I don't really like this<br>
idea as it would mean we need to rename all these files and add rules<br>
to our both build systems to process each of these files with intltool.<br>
</blockquote><div><br>This workflow is what I was asking about, I have a <a href="http://filetype.latex.in">filetype.latex.in</a> with the appropriate key marked but intltool ignores it, is there something somewhere else that needs to be set to make it work?<br>
<br>Do we have to do it for all filetypes files or only those which need it (latex initially).<br><br>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.<br>
<br>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.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
I'd even rather prefer to have unlocalised English labels by default<br>
since the user can change them now as necessary though this isn't<br>
really nice too.</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
A third possibility would be to list the necessary translatable strings<br>
for the labels in some source file like src/build.c so that the gettext<br>
translation system will pick them up by default and they get localised<br>
by the busy translators and then after reading the label texts from the<br>
filetype definition files, we feed them to gettext() to get the<br>
translation before displaying them. This would be probably the easiest<br>
way while it feels a bit hackish.<br>
</blockquote><div><br>Desperatly trying to avoid this :-(<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
What do the others think?<br>
<br>
<br>
Regards,<br>
Enrico<br>
<font color="#888888"><br>
--<br>
Get my GPG key from <a href="http://www.uvena.de/pub.asc" target="_blank">http://www.uvena.de/pub.asc</a><br>
</font><br>_______________________________________________<br>
Geany-devel mailing list<br>
<a href="mailto:Geany-devel@uvena.de">Geany-devel@uvena.de</a><br>
<a href="http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel" target="_blank">http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel</a><br>
<br></blockquote></div><br>