Forwarding Michael's message, as he is not on the list. Have a nice day, Daniel
--- Begin Message ---
- From: Michael Vogt <mvo ubuntu com>
- To: Daniel Holbach <daniel holbach ubuntu com>
- Cc: Jokosher <jokosher-devel-list gnome org>
- Subject: Re: [jokosher-devel] Moving icons
- Date: Fri, 13 Oct 2006 16:35:42 +0200
On Wed, Sep 27, 2006 at 09:48:27AM +0200, Daniel Holbach wrote: > Hello Laszlo, Hi, sorry for my late reply, the mail somehow slipped under my radar. Thanks to Daniel for reminding me about it :) > thanks for taking the time to reply and figure it out. > > Am Dienstag, den 26.09.2006, 21:09 -0400 schrieb Laszlo Pandy: > > Mostly I just want to know why > > we use need to use POTFILES.in and not just run the translations merge > > on all *.py files? > > I took a look at Michael's gnome-app-install and together with him > applied the changes to jokosher. Using POTFILES.in is the canonical way > of dealing with translations - you will find it in other projects as > well. > > I CCed Michael, I'm sure he has some *clever* reply. :-) It is there to have intltool-update working. I personally like it a lot (stuff like --maintain or --report). But of course the current makefile is fine as well if you don't need intltool-update. It can be a bit anoyning to use POTFILES.in because one needs to remember to add new files to it. The beste solution would be if the setuptools would grow gettext support one day. > > Also what happened to these two lines which grab translation template > > strings from the glade file and the instrument files?: > > > > python i18nReadInstr.py ../../Instruments/*.instr > i18n.instr.h > > xgettext -k_ -kN_ -o $@ ../../Jokosher.glade.h ../../*.py i18n.instr.h > > I'm not sure - it's been a while since I looked at it - wouldn't it > suffice to add them to POTFILES.in? [..] The format that is used in jokosher is apparently not compatible with the way that intltool expects ini files. It expects input like e.g. cello.instr.in: [core] _name = Cello icon = cello.png type = cello and will write out: cello.instr [core] name = Cello name[en] = Cello icon = cello.png type = cello So with the current way that a instr file looks like this won't work and the proposed patch needs to be reverted for this. Changing the format to something like the above may mean that code that parses desktop files can be (re-)used easily to read instr files and that intltool and can be used to scan the instr files without the need for a custom script. So it may be a win to consider that format. But I know too little about the instr format to see what drawbacks such a change might have. Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
--- End Message ---
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil