Before the final release of Fedora, the Release Notes need to be prepared for release. This process should also be executed prior to beta, but at beta there are often no translations and the beats may not be in the best of shape.
Prepare the en-US
Review all of the beats to be certain new content has not been added. If necessary, add/edit the XML to reflect changes in the beats.
Proofread the en-US and make any important corrections. Be careful not to make unnecessary changes as these will break translations, and you should strive to minimize broken translations.
Adjust the version number in Revision_History.xml. For release notes, the version is of the form x.y, the x reflects the release of Fedora and y represents the change ordinal for the XML. For alpha and beta, x should be the Fedora release number minus 1, and y is 95 for Alpha and 98 for Beta. XML release notes are generally not produced for Alpha.
The RPM (and tar) version will be x.y.z where z represents the tar file ordinal. Typically the tar file will change as new translations are added, so new tars might be produced even in the absence of XML changes.
Remove the draft status in Release_Notes.xml.
Don't forget to push these changes back to git.
Make a clean working copy
To ensure that you have the latest translations and the RPM ultimately reflects the git contents it is best to start with a clean clone in a clean directory so there is no confusion as to what will be packaged.
mkdir scratch mkdir scratch/temp cd scratch git clone ssh://git.fedorahosted.org/git/docs/release-notes.git cd release-notes cp en-US/* ../temp/
Note that, in a perfect world, you would not need to push anything back to git, so you could use the git:// form of the clone, but invariably there will be errors to correct and these should be pushed back, so the ssh:// form is preferred.
Build the non-en-US documents
Switch to the translation branch
git checkout --track -b f14 origin/f14
(Where the two f14's reflect the current release.)
Open the transifex page in a browser
https://translate.fedoraproject.org/projects/p/docs-release-notes/c/f14/
Again, f14 should reflect the current version.
Build the html for each of the languages to be included. Usually, this means languages at or near 100%. However, the desires of L10N change from time to time, so the actual decision as to what to include should have been agreed on with L10N much earlier.
publican build -f html -l (language code)
You should build each language individually. If you build several languages at once, a failure in one will cause all to not be built, although there will be artifacts in tmp/ that can be confusing later.
Generally, some of the translations contain tagging errors, typically in languages that use non-Latin character sets. Usually these errors are fairly easy to locate. They may be corrected by editing the appropriate po file. Emacs happens to be especially smart about po files, so unless you are skilled at using Emacs on po files you may prefer to use gedit, which doesn't try to out-guess you. In addition, gedit's color coding makes it easier to spot the problems.
When you get the language to build properly, push the changes back to git.
If you find you cannot build a particular language:
rm -Rf tmp/(language code)
Build the en-US document
cp ../temp/* en-US/ publican build -f html -l en-US
Since you previously built the en-US there should be no errors.
You do not want to push the en-US back to git. This will happen the next time the POT files are updated.
Review your work
Look inside each tmp/(language code)/html directory. It should contain multiple html files. Each should contain the same names, but most importantly, there should be an index.html file.
You are now ready to build the tar with doc-publican-rpm.