On Fri, 17 Jul 2009 08:04:58 +1000, Lex wrote: >2009/7/17 Enrico Tröger <enrico.troe...@uvena.de> > >> On Wed, 15 Jul 2009 11:27:42 +1000, Lex wrote: >> >> (sorry for the delayed responses, I try to catch up all the other >> mails soon :( ) >> >> >> 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? >> >> Did you also add it to the build system to get it preprocessed by >> intltool? For waf it would be adding a new build task in the build() >> method, similar to what the task for geany.desktop.in looks like. >> I'm not how to do it with autotools but it's also possible as we also >> process the geany.desktop.in with intltool with autotools. >> >> Will have a look later then, (my autotools aversion is well >> known ;-). > > >> >> >Do we have to do it for all filetypes files or only those which >> >need it (latex initially). >> >> If we really would go this way, it should be easy to only process >> these files which are necessary. But I don't like this at all. >> >> >> >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. >> >> I don't expect any noticeable troubles but I just don't like the idea >> of preprocessing these files much. It would end up in some filetype >> definition files with the .in extension, some without. Additionally, >> the build time increases and the code to maintain. >> These are all not strong arguments and I'm not completely against it, >> just want to mention I personally don't like it too much. >> >> Well, I don't mind leaving it at English since thats what I use, but >> the >facility is there if there is an easy way of using it. As I said >above I will have a quick look later on, but won't spend much time on >it, help welcome.
So, let's keep them in English for now. If I have time and am bored enough, I will have a look at some time. If your branch is finally merged and I didn't have had a look at this time, I forgot it :). Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc
pgprifmI9NYdy.pgp
Description: PGP signature
_______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel