[Geany-devel] intltool usage question

[Enrico Tröger]

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.


>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.


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/20090716/4d4b110a/attachment.pgp>