[RFC] Second take for "messages" targets

[Nicolas Goutte]

On Saturday 17 September 2005 13:47, Stephan Kulow wrote:
> Am Donnerstag, 15. September 2005 19:24 schrieb Nicolas Goutte:
> > We would probably also need a FORCEPOTFILE (replacing POTFILE)
> > for playing with cross-module naming of the POT file, like done in
> > kdebase for defining a POT file in kdelibs' PO  directory.
>
> Hmm, I think you're overdesigning a bit here. 

Well, in the "first take", I had not told enough, making that the discussion 
turned into Bash versus Posix.  So for the second take, I have prefered to 
list *every* case where I have thought that it was needed. (Then we can 
simplify or adapt.)

As for FORCEPOTFILE versus POTFILE, it is more to control the path. (We have 
already had cases of fake/wrong paths. so I want to avoid any path in the 
normal POT file name.)

> I think, requiring sh (or
> python later) for the complicated cases is not asked too much for such a
> simple task (and sh is really the best suited language for things calling
> external commands and file globbings a lot).

Anyway for complex cases, you will always need scripts whatever the solution. 
(The only simplification can come form alllowing to write POT files directly. 
Even that is not really a simplification for the scripts, it is only an 
improvement for the translators.)

(Just note that currenlty many scripts for extracting data are in Perl, 
starting by extractrc and extractattr.)

>

> We just need to define the _really_ simple cases somewhere. But for most
> it's really just the name of the potfile 

Yes, but I have avoided to define if the default is only one directory or if 
it is all sub-directories, as KDE has both in quantity.

"All sub-directories" is perhaps the prefered mode, as it avoid the one POT 
file per directory of some parts of KDE.

> and that can very well be parsed
> ou t of a Makefile.am/SConstruct file - no need for a special file.
> And having a SConstruct file per POT file isn't asked too much either. So
> you would either have a comment or a dummy function call to trigger on.
> E.g. env.PrepareMessages('kpat.pot') or
> env.PrepareMessages('konqueror.pot', 'messages.sh')
>
> then we could add a "scons package-messages" easily.

Well I do not know Scons yet. If you think that it fits in Scons, then it is a 
good thing.

My specification is quite flexible, as key-value pairs can be expressed in 
many other ways (including as paramaters of functions.)

>
> Greetings, Stephan

Have a nice day!