[Kde-scm-interest] scripty questions

[Chani]

On May 23, 2009 02:18:23 Albert Astals Cid wrote:
> A Dissabte, 23 de maig de 2009, Chani va escriure:
> > I have a plan for making scripty accept git modules, but it's bedtime
> > now, so I want to dump a bunch of questions here in hte hopes that
> > there'll be answers in hte morning :)
> > there's one possible snag, btw... well, I'll get to that...
> >
> > first, there are some scripts that don't seem to be called from anywhere.
>
> l10n-kde4/scripts != scripty

yes, atm I'm assuming that "scripty" means "scripts that are needed for 
makemessages to run". that wasn't at all clear...

>
> > is merge.sh obsolete? can it be deleted?
> > repack-pot.pl isn't used right now; can it be deleted?
>
> repack-pot.pl is used in update_translations and this is part of scripty

no it's not. update_translations passes it off to extract-messages, and the 
code that used to use it there is commented out.

>
> > ? why's there a copy of it in l10n-support
> > too?
>
> Because l10n-support is some kind of experiment for improving l10n and
> needs it
>
> > why does process_orphans.txt look like nothing has ever been deleted
> > from it?
>
> Because it was not

why? just because nobody bothered? it wouldn't break anything to get rid of 
all that old stuff? :)

>
> > what's lbundle-check.py?
>
> scripty does not touch l10n-support at all, forget about it

just because it's not part of scripty, doesn't necessarily mean it's 
irrelevant for switching modules to git. becsides, I'm curious. :)

>
> > does it read/write files outside of l10n
> > folders?

and the answer to this question is important. although I might be able to 
figure it out myself now that I've got some sleep.

>
> > why are we extracting messages from qt?
>
> Because we need to translate it and Qt did not have a good track accepting
> external contributions

hmm. now that qt's got that git repo maybe they'll be more open to 
contributions. something to look into someday, perhaps.

>
> > if I was to move the scripty files into their own folder to separate them
> > from the non-scripty files, would I have to change anything apart from
> > those files and makemessages?
>
> l10n-kde4/scripts/update_translations and kde-common/makemessages at least,
> but why risk breaking it?

because it's confusing. I had to draw a frigging UML diagram of what calls 
what, and it took most of yesterday.

>
> > scripty's extract-messages takes care of making rc.cpp from all the ui
> > files - but some Messages.sh do that too. is this a bug in those
> > Messages.sh?
>
> Not exactly a bug, but most of the times it wouldn't be needed. If you look
> carefully you'll see extract-messages only adds files of the same dir to
> rc.cpp, so programs like kmail need to create their own rc.cpp because need
> to include .ui files that are not in the same directory than the
> Messages.sh. But this can't be put in extract-messages itself because for
> example Okular has various Messages.sh if you make extract-messages find in
> all dirs it'll create "wrong" po files.

ahhh. cool.

>
> > now, the problem: documentation/ is full of svn externals. absolutely
> > full of them.
> > if this folder is only used by scripts (and people running the scripts
> > who know what they're doing), then I should be able to write a script to
> > fetch the code from git. but if translators expect this folder to be full
> > of docbook files when checked out, that could be bad, when half those
> > files are in git. (btw, only a couple of the externals successfully
> > checked out when I tried anyways. svn: No such revision 971664 )
>
> update_xml needs those files to be there.
>
> > the best thing I can think of in that case is asking the translators to
> > run a script to update documentation/ after they svn up (or checkout).
> > which isn't ideal.
> > so, do translators need it?
>
> Yes, as said update_xml needs it

so... regular translators are running update_xml... why? to see what the 
translated docbook looks like all put together instead of as little fragments 
in a po file?

>
> > if so, is it a big deal to run a script after svn up?
>
> It's a step backwards

obviously.

> > are there any other ways of dealing with this?
>
> You could make update_xml fetch the needed docbooks, but that'd be putting
> more strain in the server, tough update_xml is not called that often so
> it'd be an option.

hmm. yes, perhaps I could. I don't think it would put more strain on than 
pulling the externals, though. the svn stuff could stay as externals, and then 
the git stuff could be fetched when the script is run (or updated if it's 
already there). the only thing that might make it slow or bad for hte (git) 
server is if git makes it really hard to take only the doc folder from the 
repo.

>
> > also, the documentation/ folder *is* treated as readonly, right?
>
> It's a svn external, you can't commit into svn externals.

good :)

thanks for the answers.

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090523/71bba938/attachment.sig