[Kde-scm-interest] scripty questions

[Albert Astals Cid]

A Dissabte, 23 de maig de 2009, Chani va escriure:
> 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...

That's it, scripty is the svn user that commits the execution of the script 
that runs daily on l10n.kde.org that basically calls makemessages.

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

Right, but why would you want to delete it? It's a script that does what it 
says and it can be useful.

>
> > > ? 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? :)

Because gives us a quick access to history of what was moved where, what was 
removed, etc and regularly teams screw up and commit old files and looking 
here it's easy way to move where it belongs.

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

l10n-support is Chusslove realm, ask him, no idea if he is on this list, i 
already told you on IRC that kde-i18n-doc list would have been a much better 
list for these questions since it's where the people with i18n knowledge is.

>
> > > 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 generate the docbook files that are real documentation, documentation po 
files are just there to ease translators life and are not used at all after 
update_xml is called

> to see what the
> translated docbook looks like all put together instead of as little
> fragments in a po file?

To see the docbook "compiles" the fact that docbook is a "relatively complex" 
language makes translators generate po files that when merged back to docbook 
don't "compile"

Albert

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