> > > splitting huge files makes life for translation teams easier. Therefore I > > > am always +1 for splitting. > > > > > > The functions source xml-files are read for review : > > > http://www.holliwell.de/security/security.tar.bz2 > > > along with the compiled security chapter: > > > http://www.holliwell.de/security/ > > > > As it seems there are some small changes made with this split (a title > > was added for the intro sectin). Since the split would be good to be done > > for all languages, this is not a good idea, as the change is hard to > > track with the split. Changes should be made IMHO after the split. > > I consider this rather a real split of the security chapter, than just a > "normal" change in the en version. Trans teams can pick them up as they find > the time. > Btw, as long as the old index.xml is splitted up, the new one with changed > content would replace the original one. So there is no version we could refer > to claimed by "Last change was don in Rev..."
Well, technically the split just removes a lot of lines from security/index.xml and adds a few, so the old change history will be kept on the file. It might be enough to just add a comment to index.xml that what was the last version before the split, so translation people can pick up the changes between their revision and that revision before splitting. That also provides a good reason not to split the file in the translations, since the monolitic index.xml will still work, and it seems to be easier to let translations teams split the files themselfs after they picked up the changes done before the split. It is still important BTW that there should be no content change in the split. If a content change is needed (eg. new section title, etc), then that should be done in a separate commit on the splitted files. BTW the sections need to be elevated one level, so the section/section oddity in the TOC can be solved. But these should be done after the split IMHO. Goba
