[Geany-devel] intltool usage question

[Enrico Tröger]

On Fri, 17 Jul 2009 08:04:58 +1000, Lex wrote:

>2009/7/17 Enrico Tröger <enrico.troeger at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20090717/4ec13c9d/attachment.pgp>