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. Cheers Lex > > 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 > >
_______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel