Hi Ulf, thanks for the work on adding the autoconf stuff to the Makefile. On Tue, Aug 26, 2008 at 08:10:07PM +0200, Ulf-D. Ehlert wrote: > Roman Joost (Montag, 25. August 2008, 22:19): > > We have to do this manually unfortunately. There is no better way > > around this IMHO. A program would also only be able to just guess. > > Let's face the advantages: we do have some time for clean up ;) > > Either clean up or try to patch 'xml2po', so that it can handle those > problematic cases. I wonder what xml2po should do in those cases. Just include the strings of the next siblings seen from the current HTML node, in the translation? Could try to check if that works ... > > If no one of the authors votes for step 1, than I propose a migration > > using step 2 the next weekend. > > Meanwhile I have committed a simple shell script you can use to extract > localized XML files, e.g. > > mkdir -p tmp/xx > bash tools/profile-xml.sh --srcdir oldsrc --destdir tmp/xx --lang xx Nice! I'll try it... > > We do need a fixed date anyways, where we start the migration. That > > means, that after the date only the work and the cleanup on the po > > files continues. > > After starting the migration we should keep the current multi-lang XML > files up to date untill we definitely know everything works. Do you > mean that with "the work"? No - I actually mean, that we only work on the po files and add new content by editing the XML based on our reference language (English that is). Keeping track of two content holders sounds double work to me. If the content migration goes well, I don't see any reason why we should manage the content using gettext and besides also in the multilangual XML file. That would mean we have to make the migration probably a second or third time. How do we know, that 'definitly everything works?'. That's why we do this on a branch, test it, do the migration and finally merge with the current TRUNK. > BTW, I think we should remove any entries before 2008-07-30 from the > branches/xml2po-support/ChangeLog file. Why do we want to do that? Doesn't make any sense to me... > And maybe it's a good idea to split (and compress?) the trunk/ChangeLog > file (1.4MB!). We could rename the ChangeLog to ChangeLog2.4 or something and start from scratch a new one. Sounds good to me. Greetings, -- Roman Joost www: http://www.romanofski.de email: romanofski@xxxxxxxx
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Gimp-docs mailing list Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
